The oauth docs says
Each access_token is valid for 1 hour and each refresh token is valid for 14 days. To use the refresh_token to get a new access_token, make a POST request to https://api.box.com/oauth2/token
In this response, you’ll receive both a new access_token and refresh_token. The refresh_token you used to make this request is no longer valid.
Questions:
1) If by chance I am not able to store this new refresh_token then the old refresh_token is invalidated?
2) Can't there be refresh token which is valid always and we generate only access_token?
Yes, when a new refresh_token is created, the previous one is invalidated.
Part of the OAuth 2 spec includes invalidating old refresh_tokens in exchange for a new one. It's not the most gripping read, but you can see all of that here: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-31
Actually, we just changed this so that we don't get rid of your old refresh token until you've used the new access token.
Related
The GitLab access_token has an expiry time of 2hours, similarly does the refresh_token also has some expiry time?
Because sometimes, when I use the refresh_token to get new access_token it throws invalid_grant error.
I am thinking refresh_token does not have any expiry_time.
I am thinking refresh_token does not have any expiry_time
Indeed but they are linked to access_token.
In "Supporting Expiring OAuth Access Tokens for GitLab", GitLab explains:
How do you handle expiring tokens?
Once a token has expired, your API requests will fail and you will be
prompted by GitLab to generate a new token.
To do this, you must make another request to GitLab’s OAuth endpoint.
Much like the initial link, you must provide your application’s Client
ID and Client Secret, but instead of passing the linking code, you
will pass in the user’s refresh token.
This will invalidate both the existing access token (if it is still valid) and the refresh token you just used, and return a new
access token and refresh token.
The access token will be valid for another two hours. You will need
to store the new refresh token, as this token will be used the next
time you request a new token.
Currently I am using /token endpoint to obtain an access token, an ID token (by including the openid+offline_access scope), and a refresh token for the Authorization Code flow. The value for code is the authorization code that I receive in the response from the request to the /authorize endpoint.
Also to refresh access token as well as an ID token, I am sending a token request with a grant_type of refresh_token.
Below is the reference link, I am trying similar to implement in my custom OIDC application.
https://developer.okta.com/docs/guides/refresh-tokens/main/#renew-access-and-id-tokens-with-spas
Does it suppose to return both refresh_token and id_token OR both are optional if grant_type=refresh_token (also in token endpoint openid+offline_access scope added) in OpenID Connect concept?
Below is the link I am trying to understand.
https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokens
When you use the refresh token, the purpose is to get a new access token. Optionally, depending on the backend configuration, you might get a new refresh token as well (if you use a one-time refresh token setup).
You never get a new ID-token back, the ID token is usually a very short-lived token (like 5 minutes) and its main purpose is to describe how the user is authenticated and who it is. The main purpose of the ID token is to create the local session (typically a session cookie), after that the ID token has no real use.
I am implementing an OAuth2 server that supports refresh token however, there is something that I am not been able to understand fully.
When a user request for a new access token via the refresh_token grant_type and he/she requested lesser scope (3 out of the 5 scopes) than what the original access token has. Should the refresh token have the original scopes or should the refresh token have the new scopes requested?
If the refresh token has the new scopes requested, does this mean that eventually, they will run out of scopes if they keep requesting lesser scopes?
Should the refresh token keep the original scopes? This would mean that an access token returned would have different scopes as to what is stored in the refresh token, and the next request to get a new access token may result in more scopes than the current access token.
Can someone please enlighten me on this issue?
I have read the RFC docs and there is a point that states
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.
For a refresh token grant:
The base behaviour is to receive only a new access token in the response
The original refresh token is then reused a number of times.
Some authorization servers support refresh token rotation and may also:
Issue a new 'rolling' refresh token
This is bound to the original scopes and session time
At least that's the theory, though you need to test for your particular authorization server. Vendor support from the likes of Microsoft, AWS and others varies considerably.
Quick question, couldn't find the answer here. When using the refresh token to create a new access token, will this use up the refresh token?
I had an instance where I used up the refresh token to get a new Access Token however the new access token didn't come with a new refresh token.
Does this mean that I can keep using the initial refresh token every time the access token runs out?
The Google documentation says,
refresh_token: A token that may be used to obtain a new access token. Refresh tokens are valid until the user revokes access.
Refresh tokens are valid until they are revoked, so you can use it as many times as you want if it is valid.
The following is an example of refreshing an access_token with Google OAuth.
Request
POST /oauth2/v4/token HTTP/1.1
Host: www.googleapis.com
Content-Type: application/x-www-form-urlencoded
client_id=8819981768.apps.googleusercontent.com&
client_secret={client_secret}&
refresh_token=1/6BMfW9j53gdGImsiyUH5kU5RsR4zwI9lUVX-tqf8JXQ&
grant_type=refresh_token
Response
{
"access_token":"1/fFBGRNJru1FQd44AzqT3Zg",
"expires_in":3920,
"token_type":"Bearer",
}
to conclude, refresh tokens are not expired with an access token refresh. they can be used as long as they are valid.
The behavior depends on OAuth 2.0 implementations. Google's implementation is just one example. As a matter of fact, there exists an implementation that allows an administrator to select either (1) to keep a refresh token valid after use or (2) to invalidate a refresh token after use and issue a new one.
I am following Oauth 2.0 authentication protocol.
There, it's said in the Authorization code flow after getting the Oauth Access token we need to refresh it using the refresh token if Access_toke is expired.
My question is how do we know whether the access_token is expired or not?. so that we can claim a new access token with the help of refresh_token.
your token array should look like this one.
tokens[token] = { "userID": userID, "clientID": clientID , "expires_in": expires, "refreshToken": refreshToken };
expires = current time + 30mins(assume your token will expire after 30 mins)
In your protected route you should compare current time with that expiration. If token expire, you will issue a new token using refresh token.
Just remember the time when access token will expire when you get it. When you obtain access token you can check expires_in parameter. See OAuth 2.0 specification: https://www.rfc-editor.org/rfc/rfc6749#section-4.1.4
You should also handle Invalid Token Error and get new token when old is expired. See description: https://www.rfc-editor.org/rfc/rfc6749#section-1.5