I have a short lived(both 20 mins) access token and refresh token and I want to store it in a session as below and will use it any where if required.
session.setAttribute(ApplicationConstants.OKTA_RESPONSE,token);
Please let me know whether this is correct approach or not.
If not please suggest a link or document where in I can refer.
Thanks in advance.
It will depend on your overall application architecture. It could be you are storing tokens of your client application in server for protection or it could be your server application which acts as the client.
Storing tokens secure is what mandate by specification. So in your case if you can protect session value when you are communicate with front end (ex:- JSP page) through established mechanism (ex:- SSL) I would say this is okay.
Related
I will be using a OAuth and openId connect. My application will be having a separate authorization server and resource server. I want to implement a POC.
I have few questions:
1. How to store the received access token in my application? what is best option? to store in DB or session / cookie?
2. How will the resource server validate the access token generated by authorization server?
3. How to implement session management in my application? I read that openId connect is stateless, but to validate the token I need to maintain session, very confused.
I have read a lot but could not find this scenario where Authorization and resource server are separate.
Access tokens are usually short lived. This is done for security purposes to avoid MITM attacks. So in my opinion, unless you are using long lived tokens for some reason(in which case its better to use a database), the best option would be to store the access token in the server session or cookies.
There are basically two ways to do this. Either you invoke the introspection endpoint of the authorization server(IdP) with the access token through resource server, or you can verify the token in the resource server itself using a library(nimbusds, auth0) by validating the token signature and claims. The recommended one is the second option because if there are several resources trying to validate tokens using introspection, the overhead would be too high. Also, some IdPs don't allow introspection through bearer tokens which could be problematic in the case of a public client(no client secret to use in client credentials).
I guess this depends how you application works. If you are using something like servltes, you can store the tokens in server session or cookies through the client application. When the tokens are sent to the resource server they should be send within the request header under Authorization parameter. Not exactly sure about this one.
Hope this helps. Cheers.
I was reading the documentation on the Auth0 site regarding Refresh Tokens and SPA, and they state that SPA's should not use Refresh Tokens as they cannot be securely stored in a browser, and instead use Silent Authentication instead to retrieve new Access Tokens.
A Single Page Application (normally implementing Implicit Grant) should not under any circumstances get a Refresh Token. The reason for that is the sensitivity of this piece of information. You can think of it as user credentials, since a Refresh Token allows a user to remain authenticated essentially forever. Therefore you cannot have this information in a browser, it must be stored securely.
I'm confused. From my understanding, the only way to retrieve a new access token would be to submit a new request to the Auth server, along with some form of an Auth0 session cookie to authenticate the user that is logged in. Upon receiving the session cookie the Auth0 server would then be able to issue a new Access Token.
But how is that any different than having a Refresh Token in the browser or in the local storage? What makes the Session Cookie any more secure than a Refresh Token? Why is using a Refresh Token in an SPA a bad thing?
There are a lot of misunderstandings about both cookies and refresh tokens and OAuth2.
First, it is not true that only confidential clients can use a refresh token. The OAuth2 protocol says that confidential clients must authenticate, but does not require confidential clients. Ergo, client authentication is optional on the refresh operation. See RFC 6749, Section 6, Refreshing An Access Token.
Second, you have to understand what the alternatives are:
Forcing the user to enter his or her username and password every 5 minutes (whenever the access token expires)
Long lived access tokens
Authentication via HTTP Cookies
Everybody in the world, who doesn't use refresh tokens, uses option #3. Authentication via cookies is functionally and security-wise 100% equivalent to storing a refresh token. Of course, with both tokens and cookies, there are options for where they are kept:
a. HTTP only,
b. secure (require TLS/SSL) and
c. session (in memory) vs. persistent (local, domain storage)
The "HTTP only" option applies only to cookies and, thus, may represent the only advantage of using cookies over tokens. I.e. tokens are handled via Javascript, so there's no option to keep them away from scripts. That said, the tokens are available only to Javascript from the domain of the page that stored it (or as allowed by CORS policy). So this issue can be overblown.
Of course, care must be taken to always use TLS/SSL to transmit either authentication cookies or tokens. Honestly, since we know most breaches occur from within the private corporate network, end-to-end TLS is a basic requirement anymore.
Finally, whether cookies or tokens are ever persisted, i.e. stored somewhere that survives closing the browser or even rebooting the device, depends on the trade-off you're making between usability and security - for your application.
For applications that require a higher level of security, just keep everything in memory (i.e. session cookies, tokens in a Javascript variable). But for apps that don't require as much security and really want a session life on order of days or weeks, then you need to store them. Either way, that storage is accessible only to pages and scripts from the original domain and, thus, cookies and tokens are functionally equivalent.
This is not true anymore (April 2021), Auth0 site now states a different thing:
Auth0 recommends using refresh token rotation which provides a secure method for using refresh tokens in SPAs while providing end-users with seamless access to resources without the disruption in UX caused by browser privacy technology like ITP.
Auth0’s former guidance was to use the Authorization Code Flow with Proof Key for Code Exchange (PKCE) in conjunction with Silent Authentication in SPAs. This is a more secure solution than the Implicit Flow but not as secure as the Authorization Code Flow with Proof Key for Code Exchange (PKCE) with refresh token rotation.
Please note the importance of enabling rotation in refresh token.
The refresh tokens are not used in SPAs, because in order to use it - and to get a new access token from the /token, the SPA needs to have a client secret, which cannot be stored securely in a browser. But since the OAuth 2.0 for Native Apps RFC recommends not requiring a client secret for the /token endpoint (for public clients), the refresh tokens could be used even in SPAs.
To get a refresh token, you need to use the Auth code grant, which passes the code in a redirect URL, which goes to the server hosting the SPA (which can be an extra point of attack). The Implicit grant delivers tokens just to a browser (hash part of the redirect URL doesn't get to the server).
The difference between using a refresh token and an SSO session cookie - the cookie is probably more secure, since it can be marked as HttpOnly, making it inaccessible for attacks using JavaScript code.
Update
With PKCE extension, the Authorization code flow (with a refresh token) became a recommended flow even for browser based applications. For details see the latest version of the OAuth 2.0 for Browser-Based Apps RFC.
Good question - So there is no really secure way to store any tokens on a Browser (or any other confidential info) - see links such as this. Hence Single Page Apps (SPA) should not store a refresh token - a refresh token is particularly problematic, because it is long lived (long expiration or no expiration), and if stolen then an attacker can continue to refresh access tokens after each individually expires.
It would be better to just retrieve your access token when you need it (for instance to call an API) and either store only in memory (still vulnerable to XSS / CSRF) but better - or use and forget. Then make another checkSession call next time you need an access token.
To your question - the checkSession request does not require sending a Token. It is literally as the name suggests - a "check session" against the Authorization Server to see if a Session exists. If it does, then the Authorization Server response will include a fresh access token. See here for an example usage with SPA
Please feel free to leave me comments beneath this answer if anything requires more clarification etc.
I'm trying to add authentication feature to my application.
The authentication server implements oauth 2.0
I'm not sure how to save the refresh_token. I want to save it to a file, so next time when the application starts and there is a refresh_token available, it can ask for a new access_token. The user won't need to re-login again.
But this doesn't sound secure to me, because if someone copies my file that has the refresh_token to another computer, he can hack into my account.
You are correct with the attack that you describe. Refresh tokens have to be stored securely in order to be used as intended. As I understand, you are building a standalone application. Therefore, you can rely on file system security to prevent a refresh token being copied by an unauthorized user. You may want to use encryption for the refresh token, too, but the key would need to be bound to a user's session at your local machine (otherwise, the user would need to provide it during "sign in" process in order for the application to decrypt the refresh token).
Consider reading the thread from the OAuth WG, that discusses similar problems to the one described and provides some guidance:
https://www.ietf.org/mail-archive/web/oauth/current/msg02292.html
Refresh tokens are used to obtain access (this process requires HTTP Basic Auth). So, unless user has your (id,secret) combination he can't do much about it. However, storage of refresh token must be considered very seriously.
Here's my two cents:
Store your tokens in a DB
Whenever you use refresh token to obtain access token reset the refresh token as well. (Oauth2.0 has this feature, you can let the refresh token unchanged too, but it's wise in terms of security perspective to keep it changing and updating the DB)
Hope this gives some insights!!
You are right about your concern - you should not save the refresh token. By doing so, you jeopardize your client's data (and you know the reason; you wrote it in the question).
oAuth is not supposed to work this way.
You should keep the refresh token in-memory.
I'm trying to build the foundation for my iPhone app and server. I have users who will sign up and sign in from the iPhone app. In a normal website login, the http server will provide cookies to allow the user's subsequent requests to remain authenticated. How should I handle this on the iPhone? Should I just send the user/password every single time I have a NSURLConnection GET or POST? That seems excessive. Or do I use the ASIHTTPRequest framework to use cookies. Can anyone point me in the right direction for a proper implementation?
Thanks!
Sending username and password in every request is not great.
You can use anything you want to send cookies. It's just another HTTP header. But that begs the question of what is in the cookie. It depends on what your client/server architecture is. Web apps use session keys because traditionally web clients haven't held any state so the app server had to. Native clients can have all sorts of state and so generally don't need the server to provide that.
But you need authentication. That's what things like OAuth and OAuth 2 are for. They allow you to authenticate once and then use tokens that can be invalidated server-side. Kind of like very long lived sessions without data.
They are a bit complicated but there are open source libraries for both the server and client pieces or you can roll your own. Most of the complication is on getting the original token which you can short-circuit if you own the client and server. OAuth can get pretty complicated because all requests are signed with a secret token. OAuth 2 can be as simple as a shared secret (thus requiring SSL) in a cookie.
can I use oauth token generated on server at client side ?
if yes .
will it be secure to going like that ?
I'm not completely sure I understand the question. But, in general, if you have the application token and the user token, you can use it anywhere. For instance, my application has a mobile registration or an web site registration.
Regardless of which one you do, the tokens are shared and can be used from either client.
OAuth 2.0 AccessToken can be used to access its resource in client side (or anywhere), until it expires. That is what Client-side Applications means to do.