Re: [OAUTH-WG] Lifetime of refresh token

[Jim Manico <[e-mail]>]

This is all contextual to the application. In some situations I want to 
immediately force re-authentication for all transactions above X$ such 
as banking applications. In some situations I want a permanent refresh 
token, like for Twitter like social applications. etc...etc...

- Jim Manico



On 8/28/15 10:58 AM, William Denniss wrote:
> +1 for John's suggestion.
>
> Why force users to re-authenticate after an arbitrary 30-day window?
>
> On Fri, Aug 28, 2015 at 1:41 PM John Bradley <[e-mail] 
> <mailto:[e-mail]>> 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] <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