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
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.
Since the access token is short lived, I used the refresh token to get a new access token. A successful token response will include the following (example from microsoft api doc):
`{
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
"token_type": "Bearer",
"expires_in": 3599,
"scope": "user.read%20mail.read",
"refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
}`
I have read the life time of refresh_token is valid until revoked or 90 days of inactivity. Since I'm getting a new refresh token, do I need to replace the old refresh token with this new one? if I do, how to delete the old refresh token?
Thanks!
Like access token Refresh tokens will also expire but are rather long-lived i.e., 90 days maximum time. Once Refresh token expires you need to authenticate to the application again to get a new access token and refresh token.
Also please refer MS Documents.
Is it a bad idea to use the access token also as refresh token? For example when
the access token is expired, use the current access token to generate a new token with updated token information (roles, exp time, ...).
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.
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.