Subject: [OAUTH-WG] Refresh grant and token revocation

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

Apologies for a noise on it, however I'd like to get some more 
clarifications on it.

What I thought first about the refresh grant was that a client would use 
it for getting a new access token back after it gets a 401 back from PR.

Next after seeing the comments from others it became obvious the refresh 
grant can be used to pro-actively refresh the existing token when the 
client realizes - this is what I'm really going to ask about.

I also learned about the fact a refresh grant can effectively be used to 
clone the existing token - I'd like to avoid talking about this case in 
this thread, even I got it wrong with the term 'clone' :-)

So, as far as the refresh token grant is concerned, the grant which is 
'supported' by the core spec, what are the expectations of the client
which request to refresh a still valid access token ?

I got a bit confused by the feedback that it may be per-AS specific.
If it were the expectation then I'd not see the difference between the 
core spec "refresh_token" grant and "a.b.c" custom grant.

It seems reasonable that if the client does decide to be proactive and 
use a refresh grant without using any optional scopes, and specifically 
with the main and only purpose to refresh the access token which may get 
expired shortly, it should predictably get a new access token with a new 
time lease...

And which means the old token must've gone by now and effectively 
revoked. This exactly what the client means, get me a new refreshed 
token...

I've checked the token revocation grant. It's obviously a good idea to 
let the client directly interact with the endpoint and remove whatever 
token it want to remove. However, a refresh token request (without a 
scope parameter) should have the same side-effect

Does it make any sense at all ?

Thanks, Sergey

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 30 Nov 2012 07:36:34 +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:

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

---

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

Hi,

I posted to the wrong thread, I just re-sent the correct one.

Regards,
Torsten.

Torsten Lodderstedt <[email-masked]> schrieb:

>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.
>
>
>
>------------------------------------------------------------------------
>

---

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

Hi,

it might be reasonable in some cases to revoke the old access token (if the AS actually supports access token revocation). However, I can imagine situations in clustered systems where access tokens are acquired from from the same refresh token and used independently by different nodes or modules. In this case, revocation on refresh would not be desired.

Note: In this case one would probably not use refresh token rotation.

regards,
Torsten.

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 30 Nov 2012 10:26:33 +0000

Hi,

On 30/11/12 06:48, Torsten Lodderstedt wrote:
> Hi,
>
> it might be reasonable in some cases to revoke the old access token (if
> the AS actually supports access token revocation). However, I can
> imagine situations in clustered systems where access tokens are acquired
> from from the same refresh token and used independently by different
> nodes or modules. In this case, revocation on refresh would not be desired.
>

What I'm understanding is that there are many subtleties with the way 
refresh grant can be used in different scenarios. I hope in time there 
will be more specific recommendations about the refresh grants and 
specifically about the expectations of the clients with respect to using 
such grants.
For the moment "use it when AT has expired" is the most straightforward 
case with the predictable outcome and thus the code which use the grant 
for these purposes is portable. The other uses of the grant (with or 
without the optional scope) have the application-specific outcome - so 
hopefully in time more of these application specific uses will make it 
into the spec level text - IMHO it will help users or developers like 
myself :-)

Thanks
Sergey

>     scope
>     parameter) should have the same side-effect
>