I am creating Angular single page application and I want to use JWT (JSON web tokens) with OAUTH 2.0. I was reading best practices and found OAuth 0 article which should help with it https://auth0.com/docs/api-auth/which-oauth-flow-to-use.
My app should be able to login user and keep him logged for 60 days. I know that storing access token in browser for 60 days is not very secure and it is recommended to have it short lived. So I was thinking to use Refresh Token and store it in HttpOnly Secure Cookie to not allow read it from client side Javascript, but in this auth0 article they say that this is very insecure and SPA should not use Refresh tokens, but they are not describing why.
What if my auth API code exchange endpoint return access_token in JSON response but refresh_token in HttpOnly cookie? This way I don't need to expose any system secret keys, because they are stored in auth backend API.
Can somebody provide more information and tell is it secure to store refresh token in HttpOnly Secure cookie?
SPA application uses the OAuth2 implicit flow and there is no refresh token for this flow because public client application can't store the system password safely. I would suggest to implement the OpenID Connect implicit flow and store the JWT token in local storage. This token is more secure and can't be used by any other application. You can also encrypt the token to secure the sensitive information. If you are looking for more information, please visit a short linked-in article https://www.linkedin.com/pulse/microservices-security-openid-connect-manish-singh
Along with the answer form #ManishSingh that using OpenID Connect you should use PKCE where no client secret is required.
Related
If I authenticate with OpenID connect, I can authenticate my SPA ok.
How do I use the obtained access token now to access my own REST resources?
It's a simple question, but I don't find satisfactory answers.
A prominent answer I always find is 'use oidc when you don't have a backend'.
Now that makes me wonder if ever a webapp was created that didn't need a backend.
Oidc is almost always the answer when the question of storing a refresh token in the client pops up (like in 'use oidc, it's a better architecture and ditch the refresh token') but it doesn't really explain anything.
So when the user logs in with, say Google, he obtains an identity and an access token (to ensure that the user is who he claims he is).
So how do you use this to authenticate at your own REST service?
The only real way I see it as stateless is by sending another request at the server to the provider on every request to the REST api, to match the identity to the validity of the access token there.
If not, we fall back to the good 'ol session vs jwt discussion, which doesn't quite seem to click with the oidc because now we're duplicating authentication logic.
And the good 'ol refresh token in the browser is generally promoted as a bad idea, although you can keep access tokens in the browser session storage (according to the js oidc client library), autorefresh them with the provider and that's fine then (-.-).
I'm running again circles.
Anybody can lay this out for me and please break the loop?
Your SPA (frontend) needs to add an authorization header with access token to each API request. Frontend should implement the authorization code flow + PKCE (implicit flow is not recommended anymore) + it needs to refresh access token.
Your API (backend) needs to implement OIDC (or you can use "oidc auth" proxy in front of backend) - it just validates access token, eventually returns 401 (Unauthorized) for request with invalid/expired/... token. This token validation is stateless, because it needs only public key(s) to verify token signature + current timestamp. Public keys are usually downloaded when backends is starting from OIDC discovery URL, so they doesn't need to be redownloaded during every backend request.
BTW: refresh token in the browser is bad idea, because refresh token is equivalent of your own credentials
I am completely new to oauth2. I need to implement oauth2 for securing my REST services. After reading different blog posts what I under stood is,
There are 3 things, Client,Provider and webapp.
Web app Wants to access information about the user from the provider.
If the client allows , provider will give a authorization code to the client and webapp in query string.
Now the web app will use the authorization code to obtain the access token using which it can access the resources.
Now I am bit confused regarding the authorization code. Is it secure ?
What is the life span of a authorization code? If someone else will steal the authorization code will he be able to access the user resources?
RFC 6749 recommends that the maximum lifetime of an authorization code be 10 minutes (4.1.2. Authorization Response). In other words, an authorization code expires in 10 minutes.
An authorization code is just like a ticket which is exchanged with an access token at the token endpoint. An authorization code is not an access token, so no one can access any data with an authorization code. In addition, an OAuth 2.0 server will discard or invalidate the authorization code after the exchange.
These two request have to be done over HTTPS (mandatory) since they are requests to the OAuth server which has to support only HTTPS. It's only the client/requestor server who do not have to support HTTPS, so only the Auth Code is potentially sent in clear over HTTP. But the Auth Code is useless without the client ID/Secret. Basically the point of the OAuth Code flow is that the burden of having an SSL-enabled server is on the OAuth Provider (Google/Facebook etc...) and not on the users of the APIs
Does oauth2RestTemplate or access token providers support validate token request?
Here is the flow:
Mobile/Web-App authenticated from third party Authentication server
and obtains Access-Token.
User tries to access a secured resources, and passed the Access-Token in the request, as expected by the protocol.
Is it possible to check this token against third-party server?
I found a bit similar here in the form of a refresh token.
Is validation request the part of the OAuth2 standard?
Thanks
No, OAuth2 doesn't enforce a specific token format or API for validating tokens. This is something that has to be decided independently between the resource server and the authorization server.
For example, the UAA project, which uses Spring Security OAuth2, uses signed JWT tokens, so the resource server can validate the contents without having to ask the authorization server directly. It also provides a /check_token endpoint, which will decode the token and verify that it has not expired.
The Facebook OAuth 2.0 implementation allows you to convert a client side short lived access token into a long lived token using the FB_Exchange_Token grant_type i.e.
https://graph.facebook.com/oauth/access_token?client_id={YOUR_CLIENT_ID}&client_secret={YOUR_CLIENT_SECRET}&grant_type=fb_exchange_token&fb_exchange_token={SHORT_LIVED_ACCESS_TOKEN}
My question is does Google's version of OAuth 2.0 have a similar mechanism allowing me to get the short lived token via the client side flow, pass this token off to server and have the server convert that token so we can store the refresh token?
No, Google doesn't have that functionality. You'll need to use the server-side flow.
Can you give more info on the use case (in comments below?)
I am working on a mobile application that uses an api built with ASP.NET web api framework. We decided to use ACS alongside a custm STS as a mechanism to secure the api.
We are using a custom STS because we need to authenticate users against our own identity store.
The information flow is as follows:
Mobile app calls the custom STS with user credentials.
User is authenticated against our own identity store.
Once user is authenticated an authorization code is retrieved from ACS and used to retrieve an SWT access token.
Token is returned to mobile app.
Mobile app embeds access token in authorization header and fires request to API
HTTP module in API validates the access token and data is returned if the token is valid.
Everything is done over SSL as we are using oAuth 2.0.
The problem with oAUth 2.0 is that it is at risk from man-in-the-middle attack as the SWT token issued by ACS is a raw token and not encrypted in any way. It is however, signed using a 256bit symmetric key.
We are using swt tokens because we are using an http based approach and the token fits nicely into the auth header of an http request.
Microsoft have provided some ACS security guidelines in the following post:
http://msdn.microsoft.com/en-us/library/windowsazure/gg185962.aspx
we currently implement 2 of these as we check the issuer and the audience i.e that the token was issued by our trusted issuer (ACS) and that the token was issued for the correct audience (our api).
our scenario is based on the following article:
http://msdn.microsoft.com/en-us/library/hh446531.aspx
as such WIF is not used to handle incoming tokens. WIF is only used in claims processing.
given the above mentioned scenario is there anything else that we could be doing to improve the implementation we have to secure our rest based api?
any and all comments/criticism/suggestions welcome.
Thank you.
I think you're already taking the correct approach. The most important thing is to verify if the token is signed by ACS. Never share your ACS secret key with anyone else. If they don't know the key, they cannot forge the signature.
Also do not store confidential information in the token (such as password, credit card number, etc.). You should expect the token may be obtained by someone else, but no one can forge a token with the correct signature.