Each refresh token is valid for 14 days. Why do the refresh tokens expire?
14 days was based on what is considered best practice in implementing OAuth2. See Why do access tokens expire? for a pretty comprehensive answer about why OAuth2 refresh tokens expire.
We are interested in hearing what number bigger than 14 would work for your application. We picked 14 days based on initial feedback, surveys from application developers, as well as looking at application logins by users. A high majority of users login with apps more often than every 14 days.
Can you explain your use case? What would be the ideal non-infinite refresh-interval that would give you a balance between peace-of-mind about security, and convenience
Related
I am design the app auth api with auth2.0, now I found some companies set the refresh token expire with 10 years! why design like that? it is a good practice? how long should I set the refresh token expire time?
I found the google oauth 2.0 refresh token never expired for native app: https://developers.google.com/identity/protocols/oauth2/native-app
It all depends on how often you want to to force the user login again and reauthenticate.
In some system you want the user to do this more often and in a system with for example 10 years refresh token, you don't want the user to have to login again after the first successful authentication.
It's a bad idea to set the liftime of refresh_token to 10 years like that you have a big security problem, the best implementation of refresh_token is when it is used the first time it should be revocked or a lifetime not much than access_token.
see my other answer here
Application is intended to be used by the company for managment of intercompany documentation. These documents can contain valuable information, so it must be secure application. I am using Oauth2 with access and refresh tokens. Access token is valid for 15 minutes and refresh token is valid for 1 day.
I have not found any recommended lifetime for tokens.
Is 15mins for AT and 1 day for RT good? If yes, why these values are good enough OR are not good enough?
What is optimal lifetime for AT and RT for application which must be really secure.
Thanks a lot!
Gmail vs. bank accounts.
I can't tell where your business falls under. You should sit in in a meeting with your product team and explain what happens and let them decide. It's ok if it takes some try and error to get the right number.
But for Gmail the refresh token almost never expires. I can't think when was the last time I had to enter my credentials again.
For banks, the refresh token seems to be valid for only 10 minutes and if you background the bank app then you won’t be able to get a new refresh token and so you get signed out. Like my bank of America app. If I keep the app open then the app will continue to refresh the token.
And obviously refresh token expiry time should be more than your average user's session time.
I know that (when using the authorization code "Authorization code" in OAuth), the lifetime of an access-token should be short but the lifetime of a refresh token can be long.
So I decided for my project:
access-token-lifetime: 1 day
refresh-token-lifetime: 30 days
But what is a typical lifetime of an authorization code?
Am I right that it should be really, really short?
Maybe like 1 hour or even only a few minutes?
I could not find any "best practice" for this..
All of this is standard but configurable i most identity / auth servers.
Authorization code
When the user consents an application accessing their data they are returned an authorization code. This code is only used its normally good for five minutes. anything lower than that would probably cause you issues with clock skew and there is really no reason IMO for it to be longer.
access token
Access tokens are returned after the authorization code has been exchanged. The access token. Access tokens are most often only good for 60 minutes.
Refresh tokens
refresh tokens are long lived tokens. The following are googles standard.
Refresh tokens are good for six months but this time is sliding.
If an refresh token has not been used for six months by an application then the access is revoked.
A user can also revoke the access as well at anytime.
depending upon the scope requested. Some refresh tokens expire after the user has changed their password
Again the above are just google standards. On the identity server I work on at work. I think the current settings is one month of non usage a refresh token expires.
Just found an answer on an other site:
The authorization code must expire shortly after it is issued. The OAuth 2.0 spec recommends a maximum lifetime of 10 minutes, but in practice, most services set the expiration much shorter, around 30-60 seconds.
Source: https://www.oauth.com/oauth2-servers/authorization/the-authorization-response/
It depends on the provider. For some providers, it works only once. Once you exchange the authorization code for access and refresh tokens, it will expire and you can't use it the second time.
I am implementing OAuth2/OWIN/Katana Authentication/Authorization with the requirement of the tokens only living for a few minutes with a max of 10, maybe 15. If this is the case, do I need refresh tokens implemented? It is my understanding they are only a benefit for long lasting "sessions"
I am assuming you are talking about a custom implementation. If you are OK with the user being prompted again, then you don't need refresh tokens. Refresh tokens exist so that you can have short lived access tokens that have to be renewed often, giving you an opportunity of revoking them by invalidating the refresh token itself. If you don't need to use tokens beyond that 10, 15 mins timeframe, then you might not need refresh tokens.
I need to understand if a refresh token from OAuth 2.0 for Google data expires or not if unused for more than 6 months?
At many places it is called out that it doesn't expire and at some places it is said that it will expire if unused for 6 months.
For example, in this question, the accepted answer says that it never expires but one of the comments suggest that it can expire if unused for 6 months.
This Google doc calls out that refresh token will never expire while this doc says it can expire if not used for 6 months.
Although I am using a safety check for the cases where refresh token is expired due to any reason, but still want to make sure I understand the behavior correctly.
You are correct the two pages Using OAuth 2.0 for Web Server Applications and Using OAuth 2.0 to Access Google APIs don't have the same information.
Using OAuth 2.0 to Access Google APIs is correct.
You should write your code to anticipate the possibility that a
granted token might no longer work. A token might stop working for one
of these reasons:
The user has revoked access.
The token has not
been used for six months.
The user account has exceeded a certain
number of token requests.
There is currently a 25-token limit per Google user account. If a user
account has 25 valid tokens, the next authentication request succeeds,
but quietly invalidates the oldest outstanding token without any
user-visible warning.
If you need to authorize multiple programs, machines, or devices, one
workaround is to limit the number of clients that you authorize per
user account to 15 or 20. If you are a Google Apps admin, you can
create additional admin users and use them to authorize some of the
clients.
A refresh token that hasn't been used for 6 months will expire.
I have sent in a bug report on the first URL. Google should clear up the discrepancy the next time they go though the documents.