Subject: [OAUTH-WG] access tokens & refresh tokens of different scopes

From: Lewis Adam-CAL022 <[email-masked]>
Date: Wed, 31 Oct 2012 17:00:50 +0000

I have a use case where I would like to request both an access token and a refresh token, but I would like the access token to have a scope less than that of the refresh token.  It is standard OAuth behavior for using the refresh token to request additional access tokens (of equal or lesser scope) but the first access token that comes back always has the "master scope" of the refresh token.

For various security concerns, I always want my access tokens to be of a stricter scope that the refresh token.  For example, consider the scenario of a structured (JWT) access token that does not require the RS to call back to the AS introspection endpoint.  Following typical OAuth guidance, it is best practice to use short lived access tokens with long lived refresh tokens.  But I'd rather a compromised access token not compromise access to ALL my resource servers.

Using the existing standard I could simply destroy the first access token when it is received and then request another of lesser scope using the refresh token, but now I've just wasted a round trip over the air, consuming bandwidth and adding latency to the end user experience.

Is there anybody in the working group that feels this would be valuable?

adam

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Wed, 31 Oct 2012 19:54:35 +0000

Hi Dick,

I guess one thing that didn't quite come out in my first explanation is that the scopes could belong to different resource servers.  So I'd rather not hand RS1 an access token that can be used to access protected resources on RS2 or RS3.  That is too much power for any RS to have :)

Granted if I were using a holder of key profile of OAuth (something I am also very interested in) that could prevent such a thing from happening.  But even with that in place, it seems ugly to send a set of scopes to an RS that only supports a subset of those scopes (though I know it's done that way today).

I know a lot of my use cases are a bit atypical for the wg, but It still seems to me to be in line with the OAuth spirit to keep the access token as restricted as possible (both in terms of lifetime and in terms of scope).

adam

From: Dick Hardt [mailto:[email-masked]]
Sent: Wednesday, October 31, 2012 12:19 PM
To: Lewis Adam-CAL022
Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes

If the latency is important, you can deal with the latency by making the first call to the RS with the original access token while you are waiting for the stricter scoped access token to come back. Once you have a stricter scope access token, you can replace the original access token.

In practice, I don't think the latency is going to be an issue, and myself, I would be making a call to get a new access token just before I was going to do some work since the access token is very short lived.

-- Dick

On Oct 31, 2012, at 10:00 AM, Lewis Adam-CAL022 <[email-masked]<mailto:[email-masked]>> wrote:

adam

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Dick Hardt <[email-masked]>
Date: Wed, 31 Oct 2012 13:10:56 -0700

Hi Adam

Give your clarification, why not have 3 different calls to the AS so that there are separate refresh tokens for each RS? 

If you don't want to do that, then you will need to make the second call. I'm not too keen on making the protocol more complicated for an edge case.

btw: the only AS I know that uses refresh tokens in the social web is Google. All others have long lived access tokens IF the user granted long lived access.

-- Dick

On Oct 31, 2012, at 12:54 PM, Lewis Adam-CAL022 <[email-masked]> wrote:

> Hi Dick,
>  
> I guess one thing that didn’t quite come out in my first explanation is that the scopes could belong to different resource servers.  So I’d rather not hand RS1 an access token that can be used to access protected resources on RS2 or RS3.  That is too much power for any RS to have :)
>  
> Granted if I were using a holder of key profile of OAuth (something I am also very interested in) that could prevent such a thing from happening.  But even with that in place, it seems ugly to send a set of scopes to an RS that only supports a subset of those scopes (though I know it’s done that way today). 
>  
> On Oct 31, 2012, at 10:00 AM, Lewis Adam-CAL022 <[email-masked]> wrote:
> 
> 
> I have a use case where I would like to request both an access token and a refresh token, but I would like the access token to have a scope less than that of the refresh token.  It is standard OAuth behavior for using the refresh token to request additional access tokens (of equal or lesser scope) but the first access token that comes back always has the “master scope” of the refresh token. 
>  
> For various security concerns, I always want my access tokens to be of a stricter scope that the refresh token.  For example, consider the scenario of a structured (JWT) access token that does not require the RS to call back to the AS introspection endpoint.  Following typical OAuth guidance, it is best practice to use short lived access tokens with long lived refresh tokens.  But I’d rather a compromised access token not compromise access to ALL my resource servers.
>  
> Using the existing standard I could simply destroy the first access token when it is received and then request another of lesser scope using the refresh token, but now I’ve just wasted a round trip over the air, consuming bandwidth and adding latency to the end user experience.
>  
> [email-masked]

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Wed, 31 Oct 2012 20:29:41 +0000

Hi Dick,

Totally agree about keeping things simple :)

I'll be the first to admit that many of my use cases are edge cases, but I was sort of hoping that "this one" might find some common mindshare within the community.  Maybe it is just Google using refresh tokens today on the social web, but I think we all know that OAuth is going to have life well beyond the social web.  Whether that's good or bad has of course been the foundation of so much of the recent "entertainment" in the OAuth blogsphere :)

If I can't find anybody else in the community to agree that what I propose is useful, then I'll cry uncle and let it rest.

Btw, in response to your question "why not have 3 different calls to the AS so that there are separate refresh tokens for each RS? " ... it all comes down to end user experience / latency.

-adam

From: Dick Hardt [mailto:[email-masked]]
Sent: Wednesday, October 31, 2012 3:11 PM
To: Lewis Adam-CAL022
Cc: Dick Hardt; [email-masked]
Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes

Hi Adam

-- Dick

On Oct 31, 2012, at 12:54 PM, Lewis Adam-CAL022 <[email-masked]<mailto:[email-masked]>> wrote:

Hi Dick,

adam

From: Dick Hardt [mailto:[email-masked]<http://gmail.com>]
Sent: Wednesday, October 31, 2012 12:19 PM
To: Lewis Adam-CAL022
Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes

-- Dick

adam

---

From: Pat Patterson <[email-masked]>
Date: Wed, 31 Oct 2012 13:36:41 -0700

Away from the social web, Salesforce issues refresh tokens - see http://wiki.developerforce.com/page/Digging_Deeper_into_OAuth_2.0_on_Force.com

Cheers,

Pat
--
Pat Patterson | Principal Developer Evangelist | 408-849-4681 | http://about.me/patpatterson

On Oct 31, 2012, at 1:29 PM, Lewis Adam-CAL022 wrote:

Hi Dick,

I’ll be the first to admit that many of my use cases are edge cases, but I was sort of hoping that “this one” might find some common mindshare within the community.  Maybe it is just Google using refresh tokens today on the social web, but I think we all know that OAuth is going to have life well beyond the social web.  Whether that’s good or bad has of course been the foundation of so much of the recent “entertainment” in the OAuth blogsphere :)

If I can’t find anybody else in the community to agree that what I propose is useful, then I’ll cry uncle and let it rest.

Btw, in response to your question “why not have 3 different calls to the AS so that there are separate refresh tokens for each RS? ” … it all comes down to end user experience / latency.

-adam

From: Dick Hardt [mailto:[email-masked]]
Sent: Wednesday, October 31, 2012 3:11 PM
To: Lewis Adam-CAL022
Cc: Dick Hardt; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes

Hi Adam

-- Dick

Hi Dick,

adam

-- Dick

adam

---

From: Dick Hardt <[email-masked]>
Date: Wed, 31 Oct 2012 14:07:19 -0700

> I’ll be the first to admit that many of my use cases are edge cases, but I was sort of hoping that “this one” might find some common mindshare within the community.  Maybe it is just Google using r…

FYI: A design goal of WRAP, and hence OAuth 2.0 was to support a number of enterprise use cases. I expect people will use it in ways not imagined, which *may* require additions.

I point out the non refresh token implementations to highlight that numerous implementors have not felt the added security is worth the extra client developer overhead in case you felt that it was a requirement.

> If I can’t find anybody else in the community to agree that what I propose is useful, then I’ll cry uncle and let it rest.

It will be interesting to see if others have the same use case.

> Btw, in response to your question “why not have 3 different calls to the AS so that there are separate refresh tokens for each RS? ” … it all comes down to end user experience / latency. 

Could you not make all three calls in parallel, and then you get the access token that you want right away with no latency?

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Wed, 31 Oct 2012 21:41:03 +0000

Hi Dick,

"Could you not make all three calls in parallel, and then you get the access token that you want right away with no latency?"

Yes but it's the response time for bootstrapping the first request that is my concern.  It takes a total of 4 round trips to obtain the first down-scoped access_token (three OAuth trips + one primary authentication to the AS).

I'm really hoping more folks chime in with some interest on this one.  The security thought process behind the refresh token is sound, and I think more people will begin to adopt it.  We've got Salesforce as probably the largest enterprise using it, we've got people looking at OAuth for public safety / first responder use cases (myself), and we have FICAM profiling it as well.  I think this is just the beginning.

Just my 2 cents, it's free :)
adam

From: Dick Hardt [mailto:[email-masked]]
Sent: Wednesday, October 31, 2012 4:07 PM
To: Lewis Adam-CAL022
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes

On Oct 31, 2012, at 1:29 PM, Lewis Adam-CAL022 <[email-masked]<mailto:[email-masked]>> wrote:

Hi Dick,

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 1 Nov 2012 12:00:51 +1100

Adam,

I’ll chime in and say you have a reasonable requirement (getting tokens with different scopes (for different resource servers) efficiently). Over the last few years there have been a number of proposals for OAuth to support this (by allowing an authorization server to return multiple tokens, each with their own scope). Unfortunately, despite some support, the proposals were rejected for the core spec. There was strong resistance to any complexity that wasn’t absolutely necessary for the basic use case — and flexibility for likely (though maybe niche) scenarios such as yours was not sufficient motivation.

As it turns out, one significant early use of OAuth2 does need an extra token (the ID token in OpenID Connect). That is being supported with some additions to OAuth2 that are highly specific to OpenID Connect so it does not help your requirement.

--
James Manger

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lewis Adam-CAL022
Sent: Thursday, 1 November 2012 4:01 AM
To: [email-masked]
Subject: [OAUTH-WG] access tokens & refresh tokens of different scopes

adam

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 01 Nov 2012 07:47:19 +0100

Hi Adam,

our OAuth implementations at Deutsche Telekom issue refresh tokens and 
we use different access tokens for different RS (for privacy and 
security reasons). Today, there is a one-to-one relation between access 
and refresh token, which means a client needs to acquire and retain 
several refresh tokens. In our experience, this increases complexitity 
for the developer and causes them to use other patterns. They use a 
master access token and exchange this for other access tokens using a 
custom assertion grant type. In my opinion, it would be much simpler to 
use a refresh token instead. So we consider to use one refresh token per 
client, which can be associated with several services and thus can be 
used to obtain access tokens with different scope.

I support your requirement and would like to discuss it in the WG.

regards,
Torsten.

Am 31.10.2012 21:29, schrieb Lewis Adam-CAL022:
> I'll be the first to admit that many of my use cases are edge cases, 
> but I was sort of hoping that "this one" might find some common 
> mindshare within the community.  Maybe it is just Google using refresh 
> tokens today on the social web, but I think we all know that OAuth is 
> going to have life well beyond the social web.  Whether that's good or 
> bad has of course been the foundation of so much of the recent 
> "entertainment" in the OAuth blogsphere :)
>
> If I can't find anybody else in the community to agree that what I 
> propose is useful, then I'll cry uncle and let it rest.
>
> Btw, in response to your question "why not have 3 different calls to 
> the AS so that there are separate refresh tokens for each RS? " ... it 
> all comes down to end user experience / latency.
>
> -adam
>
> *From:*Dick Hardt [mailto:[email-masked]]
> *Sent:* Wednesday, October 31, 2012 3:11 PM
> *To:* Lewis Adam-CAL022
> *Cc:* Dick Hardt; [email-masked]
> *Subject:* Re: [OAUTH-WG] access tokens & refresh tokens of different 
> scopes
>
> Hi Adam
>
> Give your clarification, why not have 3 different calls to the AS so 
> that there are separate refresh tokens for each RS?
>
> If you don't want to do that, then you will need to make the second 
> call. I'm not too keen on making the protocol more complicated for an 
> edge case.
>
> btw: the only AS I know that uses refresh tokens in the social web is 
> Google. All others have long lived access tokens IF the user granted 
> long lived access.
>
> -- Dick
>
> On Oct 31, 2012, at 12:54 PM, Lewis Adam-CAL022 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
> Hi Dick,
>
> I guess one thing that didn't quite come out in my first explanation 
> is that the scopes could belong to different resource servers.  So I'd 
> rather not hand RS1 an access token that can be used to access 
> protected resources on RS2 or RS3.  That is too much power for any RS 
> to have :)
>
> Granted if I were using a holder of key profile of OAuth (something I 
> am also very interested in) that could prevent such a thing from 
> happening.  But even with that in place, it seems ugly to send a set 
> of scopes to an RS that only supports a subset of those scopes (though 
> I know it's done that way today).
>
> I know a lot of my use cases are a bit atypical for the wg, but It 
> still seems to me to be in line with the OAuth spirit to keep the 
> access token as restricted as possible (both in terms of lifetime and 
> in terms of scope).
>
> adam
>
> *From:*Dick Hardt [mailto:[email-masked] <http://gmail.com>]
> *Sent:*Wednesday, October 31, 2012 12:19 PM
> *To:*Lewis Adam-CAL022
> *Subject:*Re: [OAUTH-WG] access tokens & refresh tokens of different 
> scopes
>
> If the latency is important, you can deal with the latency by making 
> the first call to the RS with the original access token while you are 
> waiting for the stricter scoped access token to come back. Once you 
> have a stricter scope access token, you can replace the original 
> access token.
>
> In practice, I don't think the latency is going to be an issue, and 
> myself, I would be making a call to get a new access token just before 
> I was going to do some work since the access token is very short lived.
>
> -- Dick
>
> On Oct 31, 2012, at 10:00 AM, Lewis Adam-CAL022 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>
> I have a use case where I would like to request both an access token 
> and a refresh token, but I would like the access token to have a scope 
> less than that of the refresh token.  It is standard OAuth behavior 
> for using the refresh token to request additional access tokens (of 
> equal or lesser scope) but the first access token that comes back 
> always has the "master scope" of the refresh token.
>
> For various security concerns, I always want my access tokens to be of 
> a stricter scope that the refresh token.  For example, consider the 
> scenario of a structured (JWT) access token that does not require the 
> RS to call back to the AS introspection endpoint.  Following typical 
> OAuth guidance, it is best practice to use short lived access tokens 
> with long lived refresh tokens.  But I'd rather a compromised access 
> token not compromise access to ALL my resource servers.
>
> Using the existing standard I could simply destroy the first access 
> token when it is received and then request another of lesser scope 
> using the refresh token, but now I've just wasted a round trip over 
> the air, consuming bandwidth and adding latency to the end user 
> experience.
>
> [email-masked] <mailto:[email-masked]>