42

I have read the PODIO documentation. I have in particular contemplated the following statement concerning use of the refresh_token:

This request returns the same data as above, and you can continue to do this over and over again, to keep your application authenticated without having to ask the user to re-authenticate.

Does this mean that the refresh_token will be indefinitely valid or does it expire:

  1. X days after being issued; or
  2. X days after the last use of it for obtaining a new access_token

EDIT: Please see this PODIO Thread which asks the same questions but does not seem to give any conclusive answers about the PODIO implementation of the Oauth2.0 protocol.

Lii
  • 11,553
  • 8
  • 64
  • 88
rabbitco
  • 2,790
  • 3
  • 16
  • 38

5 Answers5

31

The answer of your question:

Does this mean that the refresh_token will be indefinitely valid or does it expire?

...can be concluded from the section 1.5 and section 10.4 of the OAuth 2.0 specification.

Section 1.5 Introduction of refresh_token states:

Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner)

section 10.4 Security Considerations for refresh_token states:

The authorization server MUST verify the binding between the refresh token and client identity whenever the client identity can be authenticated. When client authentication is not possible, the authorization server SHOULD deploy other means to detect refresh token abuse.

For example, the authorization server could employ refresh token rotation in which a new refresh token is issued with every access token refresh response. The previous refresh token is invalidated but retained by the authorization server. If a refresh token is compromised and subsequently used by both the attacker and the legitimate client, one of them will present an invalidated refresh token, which will inform the authorization server of the breach.

It can be concluded that if the authorization_server is able to verify the binding between a refresh_token and the client to whom it was issued then refresh_token can be used to obtain multiple access_token and will never expire. else the authorization sever will invalidate the old refresh_token and generate new refresh_token with every access token refresh response.

H. Pauwelyn
  • 13,575
  • 26
  • 81
  • 144
Suraj
  • 1,625
  • 1
  • 15
  • 33
  • @Sureaj: I guess the answer ultimately depends on Podio's implementation of the oath2.0 protocol. The implementation does *not* require authentication in connection with use of `refresh_token` and therefore I cannot see how they can verify the binding between a `refresh_token` and the client. It does also not apply the rotation princip as the `refresh_token` remains the same when receiving a new `access_token`. See this thread which I don't think gives any conclusive answer to my question: [Podio thread](https://help.podio.com/hc/en-us/community/posts/206669587-Get-new-refresh-token) – rabbitco Nov 14 '16 at 12:06
  • 1
    @rabbitco, yeah its totally depends on Authorization server's implementation. my answer is regarding to standard implementation RFC-6749. In your case, as Andreas Garnæs comments, refresh token doesn't exist in the database is the problem. looks like some problem at there end. – Suraj Nov 14 '16 at 14:52
  • 2
    I don't conclude the same thing from the above. I saw so many OAuth implementations with expiring refresh tokens and I doubt they all break the contract – Jan Zyka Oct 31 '19 at 15:26
  • 1
    @JanZyka The Oath 2.0 specification says "When client authentication is not possible, the authorization server SHOULD deploy other means to detect refresh token abuse." Implementing refresh token rotation policy can avoid the refresh token abuse by expiring the old refresh token. If authentication server is able to identify the bindings between refresh token and client then it is not necessary to expire the access token. And ultimately it depends on the implementation, like facebook SDK automatically refresh your access token when you make a request. – Suraj Nov 08 '19 at 08:33
17

TL; DR

Refresh token will eventually expire or become invalid and you should be ready for it.

Two scenarios:

  1. User facing service (e.g.: authorization grant flow) - maybe ok to ignore the problem, because people are good in turning it off and on again, a.k.a refresh the page :-)

  2. Server side long running service (e.g.: client credentials flow) - you should be ready for the situation when neither of access or refresh token works and re-initiate the authentication from scratch.

Real life

Refresh tokens may or may not have expiry time, depending on your provider they expire never, not as long as they're recently used, in months or in hours. Relying on the fact that you will receive new refresh token with refreshed access token may be tricky.

Timeout is not the only way in which token may become invalid. Consider following scenarios described in oauth0:

While refresh tokens are often long-lived, the authorization server can invalidate them. Some of the reasons a refresh token may no longer be valid include:

  • the authorization server has revoked the refresh token
  • the user has revoked their consent for authorization
  • the refresh token has expired
  • the authentication policy for the resource has changed (e.g., originally the resource only used usernames and passwords, but now it requires MFA)

To add to that the tokens (access, refresh) can be stored in non-persistent storage in authentication provider service so if the service is restarted (crash, update) your tokens may be gone.

Conclusion

If you are writing long-running service which needs to be reliable don't rely on being able to refresh granted authentication forever through refresh tokens.

maricn
  • 593
  • 1
  • 6
  • 21
Jan Zyka
  • 17,460
  • 16
  • 70
  • 118
6

Refresh tokens will expire X days (or hours) after their creation. Depending on your security requirements this expiration will be 1 month or 1 hour.

You have to make the decision taking care some aspects as functionality and security.

  • If you decide to priorize security, a short expiration could make your application anoying for the user.
  • If you decide to prioritize functionality, your application could be more vulnerable.
Xavier Egea
  • 4,712
  • 3
  • 25
  • 39
  • 1
    So what you are saying is that I should myself invalidate the `refresh_token` and ask for a new one? – rabbitco Nov 14 '16 at 12:10
  • 2
    @rabbitco Your refresh_token stored in DB will have an expiration date decided in the moment of its creation. After this expiration the refresh_token will be useless. So the user will have to login again into the application to create a new one. – Xavier Egea Nov 14 '16 at 12:18
  • 1
    do you now what that expiration date is? – rabbitco Nov 14 '16 at 12:48
  • @rabbitco It's what I said in my answer. The expiration of refresh_token is configurable by you. It depends on how often you will require that the users of your application have to perform a login. – Xavier Egea Nov 14 '16 at 13:35
  • 1
    Ok but what you are also saying then is that if I do not "configure" the `refresh_token` to expire then it *will* be indefinitely valid? – rabbitco Nov 16 '16 at 09:20
  • 1
    @rabbitco Yes, you can have long lived refresh tokens or even refresh tokens that never expires. But it that case, having a way to revoke them becomes more mandatory. Check this link about refresh tokens expiration in Google: http://stackoverflow.com/questions/8953983/do-google-refresh-tokens-expire – Xavier Egea Nov 16 '16 at 09:40
  • Thanks for the link to that other post - I actually consulted it before asking my question. The problem is that the answer to my question depends on Podio's implementation of the oAuth2.0 protocol. But one up vote for turning my focus to invalidating the `refresh_token` myself with regular intervals.... – rabbitco Nov 17 '16 at 09:02
0

Whether it expires or not is implementation dependent, but they can be revoked and the token endpoint will give a valid refresh token.

Whenever you obtain a new OAuth token using the token endpoint, you will always get a refresh_token value. That's the value you should use as the active refresh token. That value may change depending on the implementation.

Examples of implementation:

Regardless of implementation when the revocation endpoint is called with the refresh token, the token should be invalid.

Archimedes Trajano
  • 35,625
  • 19
  • 175
  • 265
0

Keep in mind that typically, if a new access_token is generated for a user or they reauthorize your integration, any previous access_tokens and refresh_tokens will become invalidated. This is in addition to any manual revoking of an access_token that others here have mentioned.

You might also find some helpful troubleshooting tips in this OAuth Troubleshooting guide that covers common refresh token issues as well.

Will Bishop
  • 11
  • 1