Subject: [OAUTH-WG] Refresh tokens

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 15 Jun 2011 10:30:27 -0700

The main source of confusion about refresh token is caused by the protocol lack of clear definition of access token lifetime, even in relative terms, and the objectives of refresh tokens. For example, the authorization server can issue:

- an access token good for an hour, with a refresh token good for a year or good-till-revoked
- an access token good-till-revoked without a refresh token
- an access token good-till-revoked with a refresh token, used to obtain additional access tokens for a distributed environment

In large scale systems access tokens are often self-describing, including all the information needed by the resource server to validate them. In such a setup, access tokens cannot be revoked until expired. Refresh tokens on the other hand, require a database lookup for the resource owner grant, and can be revoked.

The only real difference between the implicit and authorization code grant types is the inclusion of a refresh token. The point is not to issue long term credentials without client authentication, relying on the presence of the resource owner for authenticating the client. However, we don't say that anywhere, or define the goals of the two token types design with enough detail to offer sound security.

I would like to add a quick discussion of access token and refresh token recommended deployment setup, providing clear guidelines when a refresh token SHOULD and SHOULD NOT be issued, and when issues, how it is difference from the access token.

It's time we stop trying to accommodate every possible combination and make some hard choices.

EHL

---

From: Brian Eaton <[email-masked]>
Date: Wed, 15 Jun 2011 11:32:54 -0700

On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> I would like to add a quick discussion of access token and refresh token
> recommended deployment setup, providing clear guidelines when a refresh
> token SHOULD and SHOULD NOT be issued, and when issues, how it is difference
> from the access token.
>

Is this a start?

http://www.ietf.org/mail-archive/web/oauth/current/msg06362.html

> **
>
> It’s time we stop trying to accommodate every possible combination and make
> some hard choices.****
>
> **
>

+1.  Yes please.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 15 Jun 2011 11:56:25 -0700

Yes, this is useful and on my list of changes to apply.

But I would like to start with a more basic, normative definition of what a refresh token is for. Right now, we have a very vague definition for it, and it is not clear how developers should use it alongside access tokens.

EHL

From: Brian Eaton [mailto:[email-masked]]
Sent: Wednesday, June 15, 2011 11:33 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Refresh tokens

On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
I would like to add a quick discussion of access token and refresh token recommended deployment setup, providing clear guidelines when a refresh token SHOULD and SHOULD NOT be issued, and when issues, how it is difference from the access token.

Is this a start?

+1.  Yes please.

---

From: Kris Selden <[email-masked]>
Date: Wed, 15 Jun 2011 12:20:47 -0700

There is a scalability reason, in that the access_token could be verifiable on the resource server without DB lookup or a call out to a central server, then the refresh token serves as the means for revoking in the "an access token good for an hour, with a refresh token good for a year or good-till-revoked."

There is a security reason, the refresh_token is only ever exchanged with authorization server whereas the access_token is exchanged with resource servers.  This mitigates the risk of a long-lived access_token leaking (query param in a log file on an insecure resource server, beta or poorly coded resource server app, JS SDK client on a non https site that puts the access_token in a cookie, etc) in the "an access token good for an hour, with a refresh token good for a year or good-till-revoked" vs "an access token good-till-revoked without a refresh token."

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 15 Jun 2011 12:49:42 -0700

And we need to say that explicitly.

Even if we allow servers to use the two tokens differently, we should clearly state their design considerations and apply any needed restrictions to make that clear. We are leaving way too much to the whims of the individual developer.

Are the access tokens issued using the implicit grant short lived or long lived?
Is it valid to issue valid-till-revoked access tokens alongside refresh tokens?
What are the requirements for allowing resource owners to revoke access, when it comes to issued access tokens and refresh tokens?
Why even issue a refresh token, if the client can authenticate with the authorization server. Why not just include the client identifier and user identifier and let the authorization server lookup what the user already authorized? Yes, this requires different client identifiers for different access rights, but that's easy to do.

There are many more open questions. I have been convinced from reading the last 80 or so messages on the list, that we have given developers too much flexibility. We're at a point where I am no longer sure what's the right way of deploying this. I would like to see use enforce a common-sense approach to deploying these tokens, based on the collective wisdom and deployment experience of this group. We have enough hands-on knowledge to agree on how to narrow this down.

I am not looking for dramatic changes. I'm looking for restrictions. I want the protocol to be more helpful to developers who are not security experts to make the right decisions, and that includes me.

Yes, some use cases will suffer, but that's just what standards are about.

EHL

From: Kris Selden [mailto:[email-masked]]
Sent: Wednesday, June 15, 2011 12:21 PM
To: Eran Hammer-Lahav
Cc: Brian Eaton; OAuth WG
Subject: Re: [OAUTH-WG] Refresh tokens

EHL

---

From: "William J. Mills" <[email-masked]>
Date: Wed, 15 Jun 2011 13:24:16 -0700 (PDT)

I like your draft in general, but 

     10.1.3. Access Tokens

     Access tokens are shorter-lived versions of refresh tokens.

Doesn't work for me.  Access tokens are credentials used to access protected resources.  Refresh 
tokens are credentials used to obtain access tokens.

-bill

________________________________
From: Brian Eaton <[email-masked]>
To: Eran Hammer-Lahav <[email-masked]>
Cc: OAuth WG <[email-masked]>
Sent: Wednesday, June 15, 2011 11:32 AM
Subject: Re: [OAUTH-WG] Refresh tokens

On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav <[email-masked]> wrote:

Is this a start?

It’s time we stop trying to accommodate every possible combination and make some hard choices.

+1.  Yes please.
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Eaton <[email-masked]>
Date: Wed, 15 Jun 2011 13:39:25 -0700

Yeah, I agree with that change.

On Wed, Jun 15, 2011 at 1:24 PM, William J. Mills <[email-masked]>wrote:

> ------------------------------
> *From:* Brian Eaton <[email-masked]>
> *To:* Eran Hammer-Lahav <[email-masked]>
> *Cc:* OAuth WG <[email-masked]>
> *Sent:* Wednesday, June 15, 2011 11:32 AM
>
> *Subject:* Re: [OAUTH-WG] Refresh tokens
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 15 Jun 2011 14:01:42 -0700

+ 1

Phil

@independentid
www.independentid.com
[email-masked]

On 2011-06-15, at 1:39 PM, Brian Eaton wrote:

> On Wed, Jun 15, 2011 at 1:24 PM, William J. Mills <[email-masked]> wrote:

---

From: "Lodderstedt, Torsten" <[email-masked]>
Date: Thu, 16 Jun 2011 10:32:57 +0200

+1

Von: Brian Eaton [mailto:[email-masked]]
Gesendet: Mittwoch, 15. Juni 2011 20:33
An: Eran Hammer-Lahav
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] Refresh tokens

Is this a start?

+1.  Yes please.