Subject: Re: [OAUTH-WG] Token revocation endpoint - revoking access token vs. revoking the grant

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 13 Jul 2014 10:42:54 +0200

Hi Pedro,

can you please explain the rationale for choosing the mode dynamically?

regards,
Torsten.

Am 11.06.2014 18:20, schrieb Pedro Felix:
> Hi,
>
> In the context of RFC 7009, I've a question regarding revocation of 
> access tokens.
>
> I've a scenario where the revocation of an access token may have 
> different behaviors
>
> 1) Option 1 - just revoke the access token and not the refresh token. 
> An example is when OAuth 2.0 is being used for authentication (using 
> OpenID Connect) and we want to revoke the access token after a logout 
> but keep the refresh token for offline access
>
> 2) Option 2 - revoke both the access token *and* the refresh token.
>
> Both behaviors are allowed by RFC 7009, however there isn't a way for 
> both to be simultaneously available.
>
> My first thought was to add a custom parameter to the token revocation 
> request to differentiate between these two cases. Does this make 
> sense? Is there a better solution?
> I know that adding custom parameters breaks compatibility and should 
> only be used as a last resort.
>
>
> Regards
> Pedro
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Thomas Broyer <[email-masked]>
Date: Sun, 13 Jul 2014 11:30:31 +0200

On Wed, Jun 11, 2014 at 6:20 PM, Pedro Felix <[email-masked]> wrote:

> Hi,
>
> In the context of RFC 7009, I've a question regarding revocation of access
> tokens.
>
> I've a scenario where the revocation of an access token may have different
> behaviors
>
> 1) Option 1 - just revoke the access token and not the refresh token. An
> example is when OAuth 2.0 is being used for authentication (using OpenID
> Connect) and we want to revoke the access token after a logout but keep the
> refresh token for offline access
>
> Both behaviors are allowed by RFC 7009, however there isn't a way for both
> to be simultaneously available.
>
> request to differentiate between these two cases. Does this make sense? Is
> there a better solution?
> I know that adding custom parameters breaks compatibility and should only
> be used as a last resort.
>

I don't get it.

If you send the refresh token for revocation, then the access token should
also be revoked (as it's issued from the refresh token; you can just
consider the access token returned by the token endpoint as issued from the
refresh token returned at the same time) .
If you send the access token for revocation, then only the access token
will be revoked.

Did I miss something?

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>