Re: [OAUTH-WG] Lifetime of refresh token

[Jim Manico <[e-mail]>]

Again, I would state that this is all contextual to the application 
being built - which is why the RFC never gives specific times other than 
"short lived" or "long lived". I would suggest giving a series of 
recommendations relative to a few different risk profiles (low risk, 
social media, banking, enterprise, etc) as opposed to one recommendation.

With respect,
Jim Manico

On 8/28/15 10:41 AM, John Bradley wrote:
> I would use a 5 min AT and roll the refresh token per 
> https://tools.ietf.org/html/rfc6749#page-47 with a 1 month expiry if 
> that is what you want for a inactivity timeout after which the user 
> must authenticate again.   The user can always revoke the refresh token.
>
> Rolling the refresh token also has the advantage that if the token 
> leaks or is stollen then you will detect the second use of the expired 
> refresh token and invalidate both, so the user needs to loggin.
>
> In general I think rolling the refresh token is a good idea though it 
> is not popular, I think it is more secure.
>
> John B.
>
>
>
>> On Aug 28, 2015, at 11:21 AM, Donghwan Kim 
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>> I'm sorry to introduce a common topic.
>>
>> As John has suggested, I'm going to design that
>>
>> * An access token should be short lived e.g. 5 minutes (not to hit 
>> the AS to verify the token or 1 hour (to hit the AS to verify the 
>> token). I'm inclined to 5 minutes for stateless architecture of RSs.
>> * A refresh token should have 1 month of expiration time by default. 
>> If it turns out that some access token expired, its refresh token 
>> should refresh the token. Then, so called persistent login can be 
>> implemented regardless of the form of authentication. Only if it 
>> fails for some reason e.g. token revocation or inactivity for 1 
>> month, a user is logged out automatically and should log in again.
>> * A refresh token should be able to be revoked somehow. With 5 
>> minutes approach, it will invalidate only the refresh token (Yes the 
>> attacker can have 5 minutes at most), and with 1 hour approach, it 
>> will invalidate the refresh token as well as the corresponding access 
>> token.
>>
>> Thanks,
>>
>> -- Donghwan
>>
>> On Fri, Aug 28, 2015 at 5:43 PM, Torsten Lodderstedt 
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>     Refresh tokens are also used by public clients, e.g. native apps.
>>     OIDC allows to acquire a new id token from a refresh token as
>>     well. Note: this does not mean a fresh authentication but a
>>     refreshed id token containing the data of the original
>>     authentication transaction.
>>
>>     Am 24. August 2015 17:08:21 MESZ, schrieb John Bradley
>>     <[e-mail] <mailto:[e-mail]>>:
>>
>>         I think Nat’s diagram about the problems of doing pseudo
>>         authentication with OAuth is being taken out of context.
>>
>>         The refresh token dosen’t expire, it is revoked by the user
>>         or system.  In some cases refresh tokens are automatically
>>         revoked if the users session to the AS ends.  I think AOL
>>         typically revokes refresh tokens when sessions terminate.
>>
>>         OpenID Connect provides a separate id_token with a
>>         independent lifetime from the refresh token.  A client may
>>         keep a refresh token for a much longer time than the user has
>>         a login session with the AS.
>>
>>         Refresh tokens are typically used by confidential clients
>>         that are using a client secret in combination with the
>>         refresh token for getting a new access token.
>>
>>         By design access tokens should be short lived as the AS is
>>         expected to have a way of revoking refresh tokens but not
>>         access tokens.
>>         A access token that dosen't expire , and can’t be revoked is
>>         not a good idea.
>>
>>         John B.
>>
>>
>>>         On Aug 24, 2015, at 2:41 AM, Donghwan Kim
>>>         <[e-mail]
>>>         <mailto:[e-mail]>> wrote:
>>>
>>>         Hi,
>>>
>>>         According to Figure 2 from
>>>         http://tools.ietf.org/html/rfc6749#section-1.5, refresh
>>>         token can be used to refresh an expired access token without
>>>         requesting resource owner to sign in again (uncomfortable
>>>         experience). However, if it's true, isn't it that refresh
>>>         token might be used to request a new access token even years
>>>         later? and then isn't refresh token the same with access
>>>         token which never expires?
>>>
>>>         I intended to use refresh token to implement persistent
>>>         login by sending a refresh request before issued access
>>>         token expires (expires_in runs out). But if refresh token
>>>         works even if access token expired already, sending a
>>>         refresh request on application start up would be enough.
>>>
>>>         So I'm not sure what I'm missing about refresh token as well
>>>         as how to implement persistent login using it (you can
>>>         regard authentication here pseudo-authentication illustrated
>>>         in
>>>         https://upload.wikimedia.org/wikipedia/commons/3/32/OpenIDvs.Pseudo-AuthenticationusingOAuth.svg).
>>>         What is the lifetime of refresh token?
>>>
>>>         Thanks,
>>>
>>>         -- Donghwan
>>>         _______________________________________________
>>>         OAuth mailing list
>>>         [e-mail] <mailto:[e-mail]>
>>>         https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>         ------------------------------------------------------------------------
>>
>>         OAuth mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
-- 
Jim Manico
Manicode Security
https://www.manicode.com