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 protected]> wrote: > 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 protected]> > 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 > > > On Wed, Jun 11, 2014 at 10:06 AM, Pedro Felix <[email protected]> wrote: > 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 > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
