Subject: [OAUTH-WG] explicit request for refresh token

From: Marius Scurtescu <[email-masked]>
Date: Tue, 4 May 2010 11:41:12 -0700

Currently all flows return an optional refresh token and I think it
was mentioned that the Autonomous Client flows should never return a
refresh token.

While a refresh token will probably be used in most cases by the other
flows, in some cases the refresh token will be just ignored by the
client. Ideally in these cases the refresh token is not issued at all.

Also, Torsten suggested that when a new access token is requested then
also a new refresh token is issued, this would allow the authorization
server to detected if a refresh token was leaked and used by an
attacker. However, this will not work in all cases.

I suggest we add a parameter to the requests that normally issues the
refresh token as a hint to the authorization server that the client
wants a multi-use, single-use or no refresh token at all. This will be
just a hint, the authorization server can decide how to proceed.

For example, this parameter could look something like:
- refresh_token_type = [none | multi | single]

The default would be "none". "multi" is the normal refresh token and
"single" is the refresh token suggested by Torsten.

If the server does not support "single" type refresh tokens then it
will issue a regular token and when the access token is renewed then
it will not send a new refresh token. If for a certain flow or client
the authz server does not want to issue refresh tokens at all then it
can ignore the refresh_token_type request and just not issue one. If
"multi" is requested then either "multi" or "none" should be issued.

This refresh token type request parameter could be implemented as an
extension as well.

Thoughts?

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 9 May 2010 14:00:36 -0700

Seems like extra complexity for little gain. The only benefit is saving server resources when a refresh token isn't going to be used by the client, but since most clients are likely to use it, the saving isn't much.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Marius Scurtescu
> Sent: Tuesday, May 04, 2010 11:41 AM
> To: OAuth WG
> Subject: [OAUTH-WG] explicit request for refresh token
> 
> Currently all flows return an optional refresh token and I think it was
> mentioned that the Autonomous Client flows should never return a refresh
> token.
> 
> While a refresh token will probably be used in most cases by the other flows,
> in some cases the refresh token will be just ignored by the client. Ideally in
> these cases the refresh token is not issued at all.
> 
> also a new refresh token is issued, this would allow the authorization server
> to detected if a refresh token was leaked and used by an attacker. However,
> this will not work in all cases.
> 
> refresh token as a hint to the authorization server that the client wants a
> multi-use, single-use or no refresh token at all. This will be just a hint, the
> authorization server can decide how to proceed.
> 
> If the server does not support "single" type refresh tokens then it will issue a
> regular token and when the access token is renewed then it will not send a
> new refresh token. If for a certain flow or client the authz server does not
> want to issue refresh tokens at all then it can ignore the refresh_token_type
> request and just not issue one. If "multi" is requested then either "multi" or
> "none" should be issued.
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 10 May 2010 11:11:44 -0700

> Seems like extra complexity for little gain. The only benefit is saving server resources when a refresh token isn't going to be used by the client, but since most clients are likely to use it, the…

You could be right, it all depends on how many clients will end up
ignoring the refresh token.

The only flow where most clients will probably ignore a refresh token,
if ever sent by authz servers, is User-Agent.

Saving server resources is one advantage, the other is making the
flows a bit more secure, less chance to leak a very powerful token.

Marius