Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-02.txt

From: [email-masked]
Date: Sun, 18 Nov 2012 08:37:09 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Authorization Protocol Working Group of the IETF.

	Title           : Token Revocation
	Author(s)       : Torsten Lodderstedt
                          Stefanie Dronia
                          Marius Scurtescu
	Filename        : draft-ietf-oauth-revocation-02.txt
	Pages           : 7
	Date            : 2012-11-18

Abstract:
   This document proposes an additional endpoint for OAuth authorization
   servers, which allows clients to notify the authorization server that
   a previously obtained refresh or access token is no longer needed.
   This allows the authorization server to cleanup security credentials.
   A revocation request will invalidate the actual token and, if
   applicable, other tokens based on the same access grant.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-revocation-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-02

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 18 Nov 2012 17:40:43 +0100

Hi,

the following changed were applied to the revocation draft:
- focused draft on client-initiated token revocation, cut out 
self-care/portal stuff
- added implementation note on access token revocation.
- extended abstract
- removed normative language from introduction

regards,
Torsten.

Am 18.11.2012 17:37, schrieb [email-masked]:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Tue, 20 Nov 2012 10:58:07 -0500

Comments on the latest draft. Overall, it's in good shape, with a little 
bit of tweaking to some of the new language I think it's about ready for 
last call.

1. Introduction:
  - "cleanup" as a verb should be two words here, "clean up"
  - Remove extraneous commas, change

             "This prevents a situation, where there is
             still a valid access grant for that particular client, 
which the end-
             user is not aware of."

text to something more like:
            "This behavior prevents a situation where there is
             still a valid access grant for a particular client which
             the end user is not aware of."

2. Token Revocation:

  - grammatical parallelism, suggest wording:

               "Implementations MUST support the revocation of refresh 
tokens and
                SHOULD support the revocation of access tokens."

  - questionable whether the above is really a SHOULD, though I 
understand Google's argument for this as detailed in the Note
  - Consider moving the Note on access tokens to a Section and including 
a cross-reference to it
  - "It therefore validates..." reads awkwardly, suggest rewording with:

               "These checks are used to validate whether the token 
being presented
                 has been issued to the client presenting it."

3. Acknowledgements
  - You don't need to list my middle initial, it sounds pretentious. ;)

5. Security Considerations
  - "liklyhood" should be spelled "likelihood"
  - countermeasures: make this a normative SHOULD? or MUST?
  - "legitimate client to loss" should be "legitimate client to lose"

  -- Justin

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 21 Nov 2012 11:50:06 +0000

Hi

I'm looking for some guidance on how the client which already owns an 
access token can decide, after getting HTTP 400 back from the resource 
server it tries to access on behalf of the end user/resource owner, can 
decide that the refresh token it has can now be used to get a new access 
token.

[1] refers to various error conditions but it is not obvious to me that 
the same conditions (some of them) should or can be reported during the 
actual client accessing the protected resource.

My question is, what error condition, if any, from [1] should be 
reported back to the client failing to access a protected resource due 
to the access token being invalid or expired, so that it can help the 
client who also owns the refresh token to decide it can use it now...

Thanks, Sergey

[1] http://tools.ietf.org/html/rfc6749#section-5.2

---

From: Justin Richer <[email-masked]>
Date: Wed, 21 Nov 2012 09:11:11 -0500

There's no signaling regarding the validity of the refresh token from 
the protected resource. In more distributed setups, the protected 
resources know nothing about the refresh tokens because the PR never 
sees them. In any case. the code path is fairly straightforward, even if 
both tokens are expired:

  - client presents AT to resource
    - resource returns data, AT worked
    - [or] resource returns 400 error to client, AT didn't work
       - client presents RT to auth server
          - auth server returns new AT, RT worked
          - [or] auth server returns 400 error to client, RT didn't work
                 - client has to go get a new auth grant from the 
resource owner, start over

  -- Justin

On 11/21/2012 06:50 AM, Sergey Beryozkin wrote:
> server it tries to access on behalf of the end user/resource owner, 
> can decide that the refresh token it has can now be used to get a new 
> access token.
>
> [1] refers to various error conditions but it is not obvious to me 
> that the same conditions (some of them) should or can be reported 
> during the actual client accessing the protected resource.
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 21 Nov 2012 14:18:50 +0000

Hi
On 21/11/12 14:11, Justin Richer wrote:
> sees them.

I was just asking how the client decides it can use the refresh token, and

> In any case. the code path is fairly straightforward, even if
> both tokens are expired:
>
> - client has to go get a new auth grant from the resource owner, start over
>

the answer seems to be that whenever it gets 400 after presenting AT to 
resource it should try to use RT next to get a new AT, I guess it was 
not really obvious to me though now that I think about it, it makes 
sense, 400 at the initial try means that the current AT is not good 
enough for whatever reasons

Thanks, Sergey

---

From: William Mills <[email-masked]>
Date: Wed, 21 Nov 2012 06:53:27 -0800 (PST)

Yes, exactly right.  The client gets a hint about the AT lifespan, but must always handle the error response too.  If the AT fails with a 401 then you try a refresh.  If the refresh fails and you get a 401 response then you re-authenticate the user.  Other 4XX error codes mean something different of course.

________________________________
 From: Sergey Beryozkin <[email-masked]>
To: Justin Richer <[email-masked]> 
Cc: [email-masked] 
Sent: Wednesday, November 21, 2012 6:18 AM
Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh token
 
Hi

Thanks, Sergey

---

From: William Mills <[email-masked]>
Date: Wed, 21 Nov 2012 06:53:52 -0800 (PST)

401 not 400

________________________________
 From: Justin Richer <[email-masked]>
To: Sergey Beryozkin <[email-masked]> 
Cc: [email-masked] 
Sent: Wednesday, November 21, 2012 6:11 AM
Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh token
 
There's no signaling regarding the validity of the refresh token from the protected resource. In more distributed setups, the protected resources know nothing about the refresh tokens because the PR never sees them. In any case. the code path is fairly straightforward, even if both tokens are expired:

-- Justin

On 11/21/2012 06:50 AM, Sergey Beryozkin wrote:
> Hi
> 
> I'm looking for some guidance on how the client which already owns an access token can decide, after getting HTTP 400 back from the resource server it tries to access on behalf of the end user/resource owner, can decide that the refresh token it has can now be used to get a new access token.
> 
> [1] refers to various error conditions but it is not obvious to me that the same conditions (some of them) should or can be reported during the actual client accessing the protected resource.
> 
> My question is, what error condition, if any, from [1] should be reported back to the client failing to access a protected resource due to the access token being invalid or expired, so that it can help the client who also owns the refresh token to decide it can use it now...
> 
> Thanks, Sergey
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 21 Nov 2012 16:07:47 +0000

> 401 not 400

Yes, thanks,our code does return 401 in the client to resource path 
failure case.

I wonder it would make sense to clarify it in the future revision 
somehow. I guess it is just HTTP at the stage of the client accessing 
the resource and may be no extra clarification is needed;

That said the only place where 401 is mentioned is the section I linked 
to below which says "MAY" while 400 is also mentioned at the the top of 
the section, where the section itself deals with errors to do with the 
client requesting an access token, while the 'client to resource' path 
is not covered.
Either way, thanks for the answers/help

Sergey

>
> ------------------------------------------------------------------------
> *From:* Justin Richer <[email-masked]>
> *To:* Sergey Beryozkin <[email-masked]>
> *Cc:* [email-masked]
> *Sent:* Wednesday, November 21, 2012 6:11 AM
> *Subject:* Re: [OAUTH-WG] How the client can decide it is time to use
> the refresh token
>
> that the same conditions (some of them) should or can be reported during
> the actual client accessing the protected resource.
>  >
>  > [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Justin Richer <[email-masked]>
Date: Wed, 21 Nov 2012 15:20:54 -0500

Yes, thank you. I should have said 4XX for what I really meant there -- 
"whatever the right authorization error code is". :)

  -- Justin

On 11/21/2012 09:53 AM, William Mills wrote:
> sees them. In any case. the code path is fairly straightforward, even 
> if both tokens are expired:
>
> > I'm looking for some guidance on how the client which already owns 
> an access token can decide, after getting HTTP 400 back from the 
> resource server it tries to access on behalf of the end user/resource 
> owner, can decide that the refresh token it has can now be used to get 
> a new access token.
> >

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 24 Nov 2012 19:07:19 +0100

Hi Justin,

thanks for your review. I incorporated your comments/proposals into a 
new revision -03, which I just published 
(http://tools.ietf.org/html/draft-ietf-oauth-revocation-03).

best regards,
Torsten.

Am 20.11.2012 16:58, schrieb Justin Richer:
> Comments on the latest draft. Overall, it's in good shape, with a 
> little bit of tweaking to some of the new language I think it's about 
> ready for last call.
>
> 1. Introduction:
>  - Consider moving the Note on access tokens to a Section and 
> including a cross-reference to it

---

From: "Guangqing Deng" <[email-masked]>
Date: Tue, 27 Nov 2012 16:52:19 +0800

It seems that the client cannot know whether the refresh token should be used until a HTTP 401 error is returned from the resource server due to the expiration of current access token or some other reasons. However, a period of time cannot be ignored will be spent on obtain a new access token using the refresh token after the resource server returns a HTTP 401 error to the client, which may degrade the user experience since the real-time nature of the service cannot be guaranteed. Is a mechanism by which the client can check the validity of the access token (or the refresh token) in advance needed by Oauth? 

Guangqing Deng

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 27 Nov 2012 10:18:36 +0000

On 27/11/12 08:52, Guangqing Deng wrote:
> It seems that the client cannot know whether the refresh token should be
> used until a HTTP 401 error is returned from the resource server due to
> the expiration of current access token or some other reasons. However, a
> period of time cannot be ignored will be spent on obtain a new access
> token using the refresh token after the resource server returns a HTTP
> 401 error to the client, which may degrade the user experience since the
> real-time nature of the service cannot be guaranteed. Is a mechanism by
> which the client can check the validity of the access token (or the
> refresh token) in advance needed by Oauth?

I believe an access token response may offer an expires_in parameter 
which can provide some hint. Actually this raises an interesting question.
Suppose the client actually checks this parameter and decides to use
a refresh token it also has to pro-actively refresh its current token.

IMHO this should work even if the access token has not expired yet and 
effectively represents another form of a client-initiated revocation of 
the access token ? It will mean a client which works with the 
"expires_in" parameter can save a one round trip (the one which returns 
a failure in case of the access token being expired) ?

Does it make sense ? If it does, can some relevant wording make it into 
the revocation token draft ?

Cheers, Sergey

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 27 Nov 2012 15:29:28 +0000

The client can indeed save a round trip by proactively refreshing the access token. This does not necessarily revoke the existing access token. Many implementations do that, so your mileage may vary.

 -- Justin

On Nov 27, 2012, at 5:18 AM, Sergey Beryozkin wrote:

> I believe an access token response may offer an expires_in parameter which can provide some hint. Actually this raises an interesting question.
> IMHO this should work even if the access token has not expired yet and effectively represents another form of a client-initiated revocation of the access token ? It will mean a client which works with the "expires_in" parameter can save a one round trip (the one which returns a failure in case of the access token being expired) ?
> 
> Does it make sense ? If it does, can some relevant wording make it into the revocation token draft ?
> 
> Cheers, Sergey
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 27 Nov 2012 15:41:15 +0000

> The client can indeed save a round trip by proactively refreshing the access token. This does not necessarily revoke the existing access token. Many implementations do that, so your mileage may var…

I don't understand.

So the client will still have the existing access token which may have 
not been revoked, and then also another access token which was just 
returned in response to the refresh grant request ?

And if you mean that no actual revocation is actually done, why then 
have the client worry about doing the proactive refresh ?

I can imagine that may be that it will only be the actual refresh token 
refreshed itself, but why keep the access token if the client has 
requested a refresh ?

Sergey

>>>> *From:* Justin Richer<[email-masked]>
>>>> *To:* Sergey Beryozkin<[email-masked]>
>>>> *Cc:* [email-masked]
>>>>> [email-masked]<mailto:[email-masked]>
>>>> [email-masked]<mailto:[email-masked]>

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 27 Nov 2012 15:48:42 +0000

Yes, the client can keep two tokens and try using both of them if it wants to. I think that you're conflating revocation and expiration here, and missing a key use case: downscoping. Let's say the client gets an access grant for [A, B, C], and it gets RT and AT1 for those scopes. The client then wants to call a service with *only* scope B, so it sends RT in with scope B in the refresh request to get AT2 with that scope alone. AT1 is still valid, assuming it hasn't expired or otherwise been revoked. The client can choose which AT to present to the protected resources in different situations. 

In all of these cases, it's completely up to the AS and the PRs whether or not any of the tokens in the wild are still valid. Your AS might decide that once a RT is used, it will simply throw away all existing AT's attached to that RT. That's totally a valid use case, and the client needs to be able to handle that (in the same way that it handles any invalid token). 

If you want the clients to explicitly throw out tokens, use the Token Revocation spec.

 -- Justin

On Nov 27, 2012, at 10:41 AM, Sergey Beryozkin wrote:

> So the client will still have the existing access token which may have not been revoked, and then also another access token which was just returned in response to the refresh grant request ?
> 
> And if you mean that no actual revocation is actually done, why then have the client worry about doing the proactive refresh ?
> 
> I can imagine that may be that it will only be the actual refresh token refreshed itself, but why keep the access token if the client has requested a refresh ?
> 
> Sergey
> 
>>  -- Justin
>>

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 27 Nov 2012 16:26:12 +0000

> Yes, the client can keep two tokens and try using both of them if it wants to. I think that you're conflating revocation and expiration here, and missing a key use case: downscoping. Let's say the…
That is complex :-). Using a refresh token to downscope and keep a 
number of access tokens is definitely beyond my imagination at the 
moment, why would a client want to downscope its access token ?

Is it basically described at:
http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-03#section-3.10 ?

I'm still not getting though why access token with the richer set of 
scopes needs to be explicitly downscoped by the client, is it because 
using a token with a richer set of scopes can lead to some authorization 
issues ?

I was thinking that the down-scoping only makes sense during the 
authorization code flow where AS downscopes what the client has 
requested but obviously I'm only at the start of the learning curve :-).

> If you want the clients to explicitly throw out tokens, use the Token Revocation spec.
OK, that makes sense now.

Thanks, Sergey

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Tue, 27 Nov 2012 17:24:25 +0000

Hi Sergey,

In my use cases the client actively monitors the expiration of the AT in order to request a new AT using the RT.  We do this as you suggested, because presenting an expired AT to the RS is a wasted round trip and adds latency and degrades the user experience.  Why send the AT if we know it's expired?

As to your other question, one reason to down scope an AT ... in my use cases the AS issues access tokens for many different RS's.  It is a security concern to send an AT to RS1 that has the ability to also access protected resources at RS2 and RS3 and RSn, etc.  So I make a first request to get a "master" AT with a master RT, and then immediately destroy the master AT and use the master RT to get a down-scoped AT - one for each RS.  This is inefficient though, and I've been nagging the WG to consider a draft to allow a client to request an array of access tokens of different scopes. 

These are just my experience, and as Justin mentioned, your millage may vary.  Hope it helps either way :-)

adam

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sergey Beryozkin
Sent: Tuesday, November 27, 2012 10:26 AM
To: Richer, Justin P.
Cc: [email-masked]
Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh token

Thanks, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 27 Nov 2012 18:11:07 +0000

Hi Adam,

thanks for sharing it, helpful,
> In my use cases the client actively monitors the expiration of the AT in order to request a new AT using the RT.  We do this as you suggested, because presenting an expired AT to the RS is a wasted…

How do you know when the client is expecting a revocation and when a 
downscoping, I guess if the client includes and optional 'scope' 
parameter then it is down-scoping obviously, otherwise - revocation ?

If that is the case then IMHO a refresh token grant request without a 
scope parameter might offer a shortcut for the client not to worry about 
one more endpoint (to do with the revocation) ?

> As to your other question, one reason to down scope an AT ... in my use cases the AS issues access tokens for many different RS's.  It is a security concern to send an AT to RS1 that has the abilit…
OK, that makes it clearer. What I'm concerned about though, does the 
client need to be concerned or is it the job of AS to protect in cases 
where a token with too many scopes is used to access a given RS which 
may delegate to a stricter RS ?

I mean, is client expected to be well-behaved and know about the 
relationships between the master RS with the stricter RS1 & RS2 parthers 
? Seems not easy to make it interoperable...

Guess I'm missing the point still

Thanks, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 29 Nov 2012 21:16:46 +0000

I'd like to return to this thread. After learning about the refresh 
grant supporting a client-driven down-scoping, the same question which I 
asked in the first place seems relevant again.

If the clients gets 401 back while trying to access PR, how will it know 
how to react to it (use refresh grant with or without its optional scope 
parameter), is it because the access token has expired or is it because 
it has an invalid scope ?

Thanks, Sergey

On 27/11/12 18:11, Sergey Beryozkin wrote:
>> In my use cases the client actively monitors the expiration of the AT
>> in order to request a new AT using the RT. We do this as you
>> suggested, because presenting an expired AT to the RS is a wasted
>> round trip and adds latency and degrades the user experience. Why send
>> the AT if we know it's expired?
>>
>
>> As to your other question, one reason to down scope an AT ... in my
>> use cases the AS issues access tokens for many different RS's. It is a
>> security concern to send an AT to RS1 that has the ability to also
>> access protected resources at RS2 and RS3 and RSn, etc. So I make a
>> first request to get a "master" AT with a master RT, and then
>> immediately destroy the master AT and use the master RT to get a
>> down-scoped AT - one for each RS. This is inefficient though, and I've
>> been nagging the WG to consider a draft to allow a client to request
>> an array of access tokens of different scopes.
>>
>>> Yes, the client can keep two tokens and try using both of them if it
>>> wants to. I think that you're conflating revocation and expiration
>>> here, and missing a key use case: downscoping. Let's say the client
>>> gets an access grant for [A, B, C], and it gets RT and AT1 for those
>>> scopes. The client then wants to call a service with *only* scope B,
>>> so it sends RT in with scope B in the refresh request to get AT2 with
>>> that scope alone. AT1 is still valid, assuming it hasn't expired or
>>> otherwise been revoked. The client can choose which AT to present to
>>> the protected resources in different situations.
>>>
>>> In all of these cases, it's completely up to the AS and the PRs
>>> whether or not any of the tokens in the wild are still valid. Your AS
>>> might decide that once a RT is used, it will simply throw away all
>>> existing AT's attached to that RT. That's totally a valid use case,
>>> and the client needs to be able to handle that (in the same way that
>>> it handles any invalid token).
>>>
>>>>> The client can indeed save a round trip by proactively refreshing
>>>>> the access token. This does not necessarily revoke the existing
>>>>> access token. Many implementations do that, so your mileage may vary.
>>>>>
>>>>
>>>> I don't understand.
>>>>
>>>> So the client will still have the existing access token which may
>>>> have not been revoked, and then also another access token which was
>>>> just returned in response to the refresh grant request ?
>>>>
>>>> I can imagine that may be that it will only be the actual refresh
>>>> token refreshed itself, but why keep the access token if the client
>>>> has requested a refresh ?
>>>>
>>>> Sergey
>>>>
>>>>> -- Justin
>>>>>
>>>>>> I believe an access token response may offer an expires_in
>>>>>> parameter which can provide some hint. Actually this raises an
>>>>>> interesting question.
>>>>>> IMHO this should work even if the access token has not expired yet
>>>>>> and effectively represents another form of a client-initiated
>>>>>> revocation of the access token ? It will mean a client which works
>>>>>> with the "expires_in" parameter can save a one round trip (the one
>>>>>> which returns a failure in case of the access token being expired) ?
>>>>>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 30 Nov 2012 07:38:47 +0100

Hi,

I would assume the clients knows the scope required for a certain request (from documentation) and acquires the access token using the respective scope from the authz server. Given this assumption, 401 may only occur when the access token has expired.

regards, Torsten.

Sergey Beryozkin <[email-masked]> schrieb:

>>> From: [email-masked] [mailto:[email-masked]] On
>Behalf
>>> Of Sergey Beryozkin
>>>> If you want the clients to explicitly throw out tokens, use the
>Token
>>>> Revocation spec.
>>>>
>>>>>>>> used until a HTTP 401 error is returned from the resource
>server
>>>>>>>> due to
>>>>>>>> token using the refresh token after the resource server returns
>a
>>>>>>>> HTTP
>>>>>>> Does it make sense ? If it does, can some relevant wording make
>it
>>>>>>> into the revocation token draft ?
>>>>>>>
>>>>>>> Cheers, Sergey
>>>>>>>
>>>>>>>>
>>>>>>>>> There's no signaling regarding the validity of the refresh
>token
>>>>>>>>> from
>>>>>>>>> sees them. In any case. the code path is fairly
>straightforward,
>>>>>>>>> even if
>>>>>>>>> both tokens are expired:
>>>>>>>>>
>>>>>>>>> - client has to go get a new auth grant from the resource
>owner,
>>>>>>>> start over
>>>>>>>>>
>>>>>>>>> -- Justin
>>>>>>>>>
>>>>>>>>>