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.
Related
We have just started out with ASP.NET Web API 2 and implemented OAuth2 client credential token grant, resource owner token grant (for internal apps) as well as code flow token Grant for third party Vendors.
For code flow, when the refresh token is exchanged for a new access token and refresh token the original token is removed from the token store and as such invalidated. The resource owner can also at any time revoke an access token and its associated refresh token.
One of our vendors will follow the code flow grant as there is a requirement that the resource owner or representative authorizes the access to the resource server.
The vendor subsequently requested that instead of the normal flow to redeem the refresh token for a new access token and refresh token, that the host server automatically provide a new access token and refresh token for each request.
The idea that over and above servicing the request, the host API calls back to a pre-determined endpoint on the client domain that will provide a new access token and refresh token.
It goes without saying that such an arrangement introduces complexity within the host API and it would defeat the whole point of short lived tokens and longer lived refresh tokens and we would probably implement other measures to prevent token hi-jacking and other types of attacks.
Currently our authorization server and resource server is one and the same. We would however want to keep the option open to separate the authorization server from the resource in future.
The questions from this then:
Should we consider this arrangement at all?
Would it make sense to adjust to a never expiring access token and not issue a refresh token with the token request?
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.
The normal flow for OAuth2 as described in this SO reply is as follows:
Send API request with access token
If access token is invalid, try to update it using refresh token
if refresh request passes, update the access token and re-send the initial API request
If refresh request fails, ask user to re-authenticate
This is all well and good for most API calls, but I wonder one thing: Authentication.
When a user attempts to sign in to my fancy new webapp using their favourite service, should I use their refresh token (or cached access token in the case of OAuth1) to attempt a sign in, or should I always go and get a fresh token from the service provider (Google, Facebook, etc) and discard the stored access and refresh tokens?
User authentication and OAuth 2.0 are two different things. The difference is explained in detail in: http://oauth.net/articles/authentication/. Even when building user authentication/SSO protocols on top of OAuth 2.0 - which is what OpenID Connect does and some vendor-specific implementations - the refresh_token still always applies to the access_token not to the user authentication event or identity token.
You can not use a refresh token on its own to refresh a user's login session since some interaction with the user (may be active, may be passive) through the browser is required to confirm that the user is (still) present.
To refresh a user's login session you will always have to redirect to the identity provider and get fresh authentication information. Note that that interaction will probably also give you a new refresh token that could be used to refresh the access token.
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.
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.