I am trying to implement Oauth 2.0 provider. I am confused on access token grants. I am using oauth2orize module in node.js.
I am confused on Should I remove all access token related to specific user when user logouts from auth server? I am building mobile and single page app for browser and I am using Resource owner password credential flow. How long should access token be valid for and should it expire on logout?
Generally, an app will revoke an access token just prior to performing logout. Typically, the app will revoke a refresh token if it got one, as that will also invalidate any and all access tokens.
From the perspective of the authorization server, I would keep these things separate and implement both:
Revoke (RFC 7009)
Logout (OpenID Connect)
Then, the clients can use either / both of these as they need. If you have some constraints in your environment, you may be able to automatically revoke tokens during logout in your authorization server. Generally though, an it should allow for both to be used independently and put the client in control.
Related
We have implemented the below process for revoking OAuth access tokens / refresh tokens to de-link an external app from our application.
On logout / user initiated de-linking action, we delete the access token and refresh token that was obtained from the initial authorization flow
User has to go through the authorization flow again once again to obtain the access token and refresh token
We are not calling any token revoke function / API call to the authorization server
My question is:
Does the authorization server automatically revoke the first set of access token + refresh token if a new authorization flow has been initiated by our app?
Are there any potential pitfalls to avoid in this approach?
The reason we took this approach is because most 3rd party apps do not offer revoke access related APIs and require the user to go to the 3rd party app to remove access / de-link the authorized apps.
Does the authorization server automatically revoke the first set of access token + refresh token if a new authorization flow has been initiated by our app?
No, most won't. Consider a scenario where a user is logged into your application from multiple devices. Each would get a valid access/refresh token.
So, you can't rely on this.
As said in OAuth2 rfc6749
The implicit grant type is used to obtain access tokens (it does not
support the issuance of refresh tokens) and is optimized for public
clients known to operate a particular redirection URI. These clients
are typically implemented in a browser using a scripting language
Refresh tokens are not suitable for implicit grant.
My question is:
How a mobile app, will refresh the access_token once it expires?
How the big ones in the market are doing this? Which practices they follow?
I know it is not following security recomendations, but it´s a good practice to make an long-lived access_token in this case? It can get annoying to need to re-authenticate each 30 min you use an app, or you close and reopen it.
As necessary permissions don´t change, a silent log-in on every app start, will be a choice to consider?
You don't necessarily need a refresh token to allow continued usage once an access token expires. If you must insist your clients use the implicit flow, then they may be able to make use of cookies and redirects to keep getting short-lived tokens without user interaction. Providing your client apps are using an HTTP agent which can use permanent cookies. e.g. apps that run in a web browser.
The key then is keeping the user signed into the identity provider the first time the token is requested.
This is done for example by the Identity provider (you I guess?) creating an HTTP cookie for the user agent to persist. Most big identity providers will do this - i.e. keep you signed in.
Now, when the token expires your client app will send the user back through the Oauth process again but, because the user has remained logged in to the identity provider, the identity provider can authenticate the user from the cookie without prompting for credentials.
If your clients instigate this token renewal on a background thread they can request the token as normal and, through the magic of HTTP redirects and cookies, get back a new token from you with no user action required.
Again - this alternative to refresh tokens relies on the client device being able to utilise permanent cookies, and your users remaining signed in and your auth server handling http cookies. If your clients are using native apps this solution may not work.
As in the future you will have 100s of clients maybe your auth plaform should offer different auth flows to different clients.
This article on mobile apps and implicit flow may be of interest to you.
Native apps are supposed to use the Auth code grant. So you can use refresh tokens. There is an RFC that discusses reasons (mainly security) for that as well as platform specific details. There is an important implication - the /token endpoint of your OAuth2 provider should not require authentication for getting tokens, because your application cannot keep its client secret safe.
I'm working on a SPA app based on Node, with token-based authentication using JWT. Right now, the jwt token never expires, which is not good.
I want it to expire for more security, but I don't want my users to be forced to re-log. That's why I need a refresh token.
So i'm reading about OAuth2.
I have a hard-time to understand why refresh-tokens must be stored in a database, whereas access-token are generated on the fly using a secret key.
Why refresh tokens can't be generated the same way as access tokens ?
Thank you guys !
Refresh tokens usually are generated the same way as access tokens.
An authorization server will often return a refresh and access token if requested (and you're not using the implicit grant type).
The difference is how they are used.
An access-token is usually a bearer token: whoever has it can use it against the resource server, but it is only valid for a short period of time. In which case, storing them in a database is often pointless as they are worthless once expired.
A refresh token however is like having access to a "forge" which allows you to mint a new token.
If you present the refresh token to the authorisation server (not the resource server) you will get back a new access token and possibly a new refresh token.
Providing of course that the user has not revoked/changed access permissions to your application and that the user is still a valid user.
So you would keep them in a database perhaps because your user logs in infrequently. So you may need the refresh token weeks after you got it.
Alternative to the refresh token.
If you are using the implicit grant (which is common with SPAs but not recommended). You can try and keep your end user logged in to the identity provider used by the authorisation server. This way you can keep requesting new access tokens from the auth server without the user being prompted by the auth server for credentials as a session will be persisted between the identity provider and the user's browser.
A quick overview of the problem.
I have a client application that will use IDS to authorise access to a google service on behalf of the end user.
However, the client application isn't, itself responsible for talking to google. There is a Server app that does some magic with the user's data on his behalf.
Now, if I understand things correctly, the server app will use the Access Token supplied by the client app to talk to google. What happens when that access token expires? As I understand it the client application is expected to use the refresh token to as for a new access token.
Is there an issue with the server using this refresh token to update the access token? What flow am I supposed to use to make this magic happen?
A server using a refresh token to get a new access token is a valid use case.
If you're working with OAuth you can use the Client Credentials or Resource Owner flows to use refresh tokens, otherwise for OpenID Connect you'll need to use Authorization Code or Hybrid.
I am trying to understand the token abuse scenarios in OpenID/OAuth 2.0 context.
In the grant_type=authorization_code scenario, the access token and the refresh token are available to a client app after successful user authorization. Token refresh makes it easy for client app to keep using the user resource for a practically infinite amount of time.
Is it possible to limit the use of the access and refresh tokens by client app?
Scenario: a user would like to authorize client app access to the resource for only until he closes the browser. The tokens should be invalidated after that.
For such control, user completely depends on how the Identity Provider is implemented. It would be possible to implement Identity Provider in such a way, e.g. it could ask user when the authentication session should expire on the consent screen. However, I've never seen such an implementation. Some Identity Providers allow to revoke issued tokens manually, but this is often hidden behind deep navigation on the Identity Provider's site.