I see most of people saying when we use refresh token to exchange for a new access token, the auth server would issue a new refresh token and invalid the previous one. Refer
OAuth Refresh Token Best Practice
But from the OAuth website
https://www.oauth.com/oauth2-servers/access-tokens/refreshing-access-tokens/
It says the auth server can "optionally issue a new fresh token in response, or if we don't include a new refresh token, the client assumes the current refresh token will continue to be valid"
So, it looks like both options (keep or renew refresh token) are acceptable to OAuth2 standard.
My questions are:
1) Do both options are equally secure?
2) If the auth server returns a new refresh token but the client fails to receive (e.g. network error), the client has no way to re-gain access token with existing refresh token, which already invalidated. Correct?
3) If the refresh token has been leaked to someone else, both the attacker and the victim client can use it. If the auth server takes the renewal approach, then only the first one to use the refresh token can re-gain access token. So, if the victim found the refresh token is no longer valid, it may think that the refresh token has been compromised. Is this the reason for the "renewal approach"?
2.) Yes, that's correct.
3.) That's correct too. You can take a look at the OAuth 2.0 for Browser-Based Apps RFC which discusses the refresh token regeneration. It's important mainly for public clients - the ones without client_secret, since a refresh token can be exchanged for an access token right away.
1.) Refresh token regeneration is a security feature - it shortens validity of a stolen refresh token and it enables the auth server to detect that refresh token had been compromised. So it's more secure to use it than not. But it may be more convenient for private clients not to get a new refresh token on each use - for example to prevent the refresh token loss due to network error - as you described it in point #2.
Related
As we know that access token gives the client to access resources from resource server, I would like to know the contents and the process that happens with refresh token to get new access token.
I was tryging to experiment how oauth2 works, but got stuck at what refresh token does.
I would like to know the contents and the process that happens with
refresh token to get new access token.
Refresh token are generally opaque token (random unique string).
Refresh token is used to get new access token from the Authorization Server. Refresh tokens typically remain valid for longer time as compared to access token. In a typical client-server flow, when the access token expired, server reject the request then client uses the earlier obtained refresh token to get a new access token from Authorization Server. By doing so authentication between client and server remain uninterrupted and no re-authentication needed. Once the refresh token expired, client has to go through the complete authentication flow which usually require user intervention.
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.
I am implementing an oauth server using spring oauth. I notice that spring's implementation re issues the same access token if not expired from the token endpoint. However the behavior is different while refreshing access tokens. A new token is reissued each time, are there any concerns to keep in mind if I were to reissue the same un expired access token on receiving a valid refresh request.
The OAuth Spec section-6 specifies that:
The authorization server MAY issue a new refresh token, in which case
the client MUST discard the old refresh token and replace it with the
new refresh token. The authorization server MAY revoke the old
refresh token after issuing a new refresh token to the client. If a
new refresh token is issued, the refresh token scope MUST be
identical to that of the refresh token included by the client in the
request.
There does not seem to be a requirement that the access token is brand new.
I think the main concern is to ensure that you do not change the expiration date on an existing token. And that you correctly return to the client an accurate expires_in property which reflects when the token will expire.
In addition, it might make the semantics confusing for clients. The refresh is usually done when a token is expired, and the client wants a new one.
I can imagine some odd edge cases. A client could send a request to refresh a token a few seconds before it is expired (perfectly valid logic for a client), but still receive back the same token which is almost expired.
I'm reading through the OAuth2 RFC 6749 specs before implementing an Authorization/Resource server for the Resource Owner Password Credentials Grant.
I understand that the Client application uses the refresh_token (along with its credentials) to obtain a new access token for an End User (Resource Owner) rather than storing the End User's username/password and sending them every time an access_token expires.
However, to me this sounds like the refresh_token is as good as an access_token, it's pretty much just an extra server call, so why not use it directly i.e. if the refresh token is valid grant access?
Am I also correct to assume there is one refresh token per End User's session?
However, to me this sounds like the refresh_token is as good as an
access_token, it's pretty much just an extra server call, so why not
use it directly i.e. if the refresh token is valid grant access?
Because that extra server call to the Authorisation Server is important in ensuring access is still allowed to the client app. The resource server would not be able to verify that the refresh token is still good without talking to the Authorisation Server. But this is not the concern of the resource server.
A valid access token is a bearer token. It is used directly on the resource server to get data - no questions asked. If it's not expired, and it has the right scopes - here's the data, whoever you are!
A refresh token on the other hand has to be presented to the Authorisation Server along with client credentials. The Authorisation Server may choose to verify that the resource owner hasn't revoked access to that client, or that the client app itself is still valid. If OK the authorisation server can mint a new, short-lived bearer access token, which is as good as data to anyone who has it!
I'm fairly new to Oauth and I am wondering if a specific flow is supported by any of the Oauth flows. I want to be able to identify a user and allow that user to perform unsecure actions even after their token has expired. The user would only be forced to reauthenticate if they request to perform a secure operation. I currently do not see any flow that will support this.
I have thought of the following solution using refresh tokens but not sure I am possibly violating any oauth patterns or if there is a better way.
1) Issue access token for X amount of time. Lets say 2 hours.
2) Upon token expiration, refresh token is used to get a new access token. The new token will contain a claim that identifies that the user only has unsecure access.
3) If secure resource is requested, request will be denied with a 401 response code indicating that the token is invalid.
4) Application will have to ask for user credentials in order to receive a new access token.
Any thoughts on this?
This is really up to the interaction between the Resource Server and the Client and certainly with the boundaries of standard OAuth 2.0 . The only thing that OAuth 2.0 standardizes in that interaction is the way in which the access token is presented. All other behavior is left up to the application implementor.
The Resource Server would allow access to unsecure resources/operations regardless of the validity of the access token, or even if there's no access token presented at all. Only upon accessing a secured resource the flow would would as you describe.
I don't see value in producing access tokens that identifies "unsecure access". That token would have the same semantics as an expired token or no token at all, so there's no need for an access token to cover that case.