As I recall, the argument was that without this, someone could just keep fishing at the token revocation endpoint for valid tokens. Though thinking about it now, even if you did get a "token was valid" response, the token wouldn't be valid anymore and it wouldn't do you much good.
It's possible that "invalidation" is a better term for this, but is there an established semantic precedent for this distinction? -- Justin On May 24, 2013, at 12:13 PM, Barry Leiba <barryle...@computer.org> wrote: >> Sergey has the correct interpretation -- it's to prevent a class of oracle >> attacks. >> Think of it this way, if you go to revoke a token, and the token wasn't >> there in the >> first place, the end result is the same: the token's not there when you're >> done. So >> it's a 200 because the result is what you wanted even if the state going in >> was wrong. > > This highlights my point in my AD review: > https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/ballot/ > > ...that this is *not* revocation. It's invalidation or surrender > (requested by the bearer of the token) -- revocation would be an > action by another party to invalidate a token without the bearer's > involvement. > > The usual defense against the sorts of attacks you're talking about is > to make the failure conditions indistinguishable -- not to make > success indistinguishable from failure. That is, you have two > responses, success and failure, but the failure response doesn't say > why. > > What, specifically, is the attack you're trying to defend against > here, any why is this the best approach to that attack? I can't see > how a "please invalidate this token" request can in any way take > advantage of a "no" response to mount an attack. It's possible that > there really is a threat here and that this is the right way to handle > it, but I'd like to see that explained. > > Barry, Applications AD _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
