Subject: [OAUTH-WG] Token revocation - response status for valid token but incorrect client

From: Pedro Felix <[email-masked]>
Date: Wed, 11 Jun 2014 17:06:06 +0100

Hi,

In the context of RFC 7009, what should be the response status code if the
request contains a *valid* token but associated with a different client?

Should we consider this token to be "invalid" and return a 200? However,
the token can still remain valid (for a different client).

The RFC states

"...and then verifies whether the token
   was issued to the client making the revocation request.  If this
   validation fails, the request is refused and the client is informed
   of the error by the authorization server as described below"

However, it is not clear where is the "described below".

With a 200 status code, an implementation does not have to check if the
revocation failed due to a client mismatch or due to another reason (e.g.
token does not exist). This may allow for a more efficient revocation
procedure.

Thanks
Pedro

---

From: Brian Campbell <[email-masked]>
Date: Wed, 11 Jun 2014 11:09:43 -0600

Hi Pedro, I'm not sure it will exactly answer everything for you but there
was a thread awhile back that started with a very similar question:
http://www.ietf.org/mail-archive/web/oauth/current/msg12430.html

On Wed, Jun 11, 2014 at 10:06 AM, Pedro Felix <[email-masked]> wrote:

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

---

From: Pedro Felix <[email-masked]>
Date: Wed, 11 Jun 2014 18:35:26 +0100

Yes, that is exactly my question. However, apparently there isn't a clear
answer.
I'm not sure 200 is a valid status code, since the token may remain valid.

Regards
Pedro

On Wed, Jun 11, 2014 at 6:09 PM, Brian Campbell <[email-masked]>
wrote:

>> In the context of RFC 7009, what should be the response status code if
>> the request contains a *valid* token but associated with a different client?
>>

---

From: Justin Richer <[email-masked]>
Date: Wed, 11 Jun 2014 13:38:12 -0400

In this case, if the client can’t revoke the token for some reason, then there’s nothing it can do if the token wasn’t actually revoked. It needs to treat the response from the server as if the token is no longer valid, regardless of what actually happened on the server. It could ask to revoke it again, or the correct client could ask to revoke it, and in both cases the server says “sure” and the client throws away the token never to use it again. That, at least, is my interpretation of the intent here.

 — Justin

On Jun 11, 2014, at 1:35 PM, Pedro Felix <[email-masked]> wrote:

> Yes, that is exactly my question. However, apparently there isn't a clear answer. 
> On Wed, Jun 11, 2014 at 6:09 PM, Brian Campbell <[email-masked]> wrote:
> Hi Pedro, I'm not sure it will exactly answer everything for you but there was a thread awhile back that started with a very similar question: http://www.ietf.org/mail-archive/web/oauth/current/msg12430.html
> 
> 
> In the context of RFC 7009, what should be the response status code if the request contains a *valid* token but associated with a different client?
> 
> Should we consider this token to be "invalid" and return a 200? However, the token can still remain valid (for a different client).
> 
> The RFC states
> 
> With a 200 status code, an implementation does not have to check if the revocation failed due to a client mismatch or due to another reason (e.g. token does not exist). This may allow for a more efficient revocation procedure.
> 
> Thanks
> Pedro
>