Re: [OAUTH-WG] Refresh tokens

[Leo Tohill <[e-mail]>]

I did some looking around regarding the lifetime of refresh tokens in
various OP services.

Auth0 <https://auth0.com/docs/tokens/refresh-token/current>,and google
<https://developers.google.com/identity/protocols/OpenIDConnect#refresh-tokens>
do not appear to support a limited lifetime on refresh tokens.
AWS
<https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html>supports
a lifetime, but with day granularity (minimum 1 day).  It does not issue a
new refresh token when one is redeemed.
IdentityServer
<http://docs.identityserver.io/en/latest/topics/refresh_tokens.html>allows
a choice of behavior on refresh token expiration time.  It can have a
absolute expiration time, or use a sliding window.

I couldn't find anything in oauth or openid specs regarding refresh token
lifetime.

I'm thinking that our language might say that "if the OP supports refresh
token (absolute) lifetime, refresh tokens may be used (in the browser), but
should (must?) specify a expiration time."





On Sat, Jul 20, 2019 at 2:54 PM David Waite <[e-mail]>
wrote:

>
>
> > On Jul 20, 2019, at 12:38 PM, Leo Tohill <[e-mail]> wrote:
> >
> > Access tokens and refresh tokens, stored browser-side, are equally
> vulnerable to theft, because the storage options are identical.
> >
> > We are more concerned about the theft of the refresh token, because it
> (commonly) has a longer usable lifetime than the access token.
> >
> > Still , its a matter of degree. Since we accept the risk of access token
> theft,  why can't we accept the risk of refresh token theft?  We ameliorate
> the access token risk by using short lifetimes, but there is no standard
> for that value: it is situational.  Why doesn't the same reasoning apply to
> refresh tokens?
> >
> > This reasoning assumes that refresh tokens also have a limited
> lifetime.  I am unsure that this is always the case.  When one uses a
> refresh token to acquire a new access token, AND that operation issues a
> new refresh token, does the new refresh token get a new lifetime?  If so,
> then a refresh token can be used to retain access infinitely (or until it
> is revoked server-side).  In this scenario, the risks associated with
> browser-side storage of refresh token are much higher.
> >
> > In summary, I'd say that IF the lifetime of a refresh token can be
> limited, then refresh tokens pose identical risk as access tokens, and so
> the same considerations apply.
>
> Agreed
>
> I think there is an unwritten framework for evaluating the security of all
> tokens, regardless of type. For example: access tokens are shared with
> resources, so their security protections in the Security BCP including
> limiting replay against other resources, and optionally against new
> requests against the same resource.
>
> Because it is complex and unwritten, it is hard to do a true evaluation.
> My impression was always that refresh tokens were more ‘risky’ for public
> clients because “offline” refresh tokens may be good for an indeterminate
> period of time, and because lack of credentials means theft of the token is
> sufficient.
>
> In addition, a public client which does not use its refresh token in an
> “offline” manner may have theft go unnoticed for a considerable period of
> time, and the operational model of public clients usually puts detection of
> local token theft in the hand of the end user and client software, not an
> administrator or organizational security staff.
>
> But those concerns are mostly mitigated if the OP can set policy to
> control refresh token usage in concert with the authentication session.
>
> -DW