Re: [OAUTH-WG] Lifetime of refresh token

[William Denniss <[e-mail]>]

+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]> 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]>
> 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]> 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]
>> >:
>>>
>>> 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]>
>>> 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]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>