I'd suggest "authorization server MAY revoke all tokens". Revoking an access token that was just issued is surprisingly tricky. Fast to verify, easy to revoke, scalable: pick two.
On Tue, Jul 13, 2010 at 9:26 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > How about: > > Authorization codes SHOULD expire shortly after they are issued to > minimize the risk of leaks. Clients MUST NOT reuse authorization > codes. If an authorization code is used more than once, the authorization > server SHOULD revoke all tokens previously issued based on that > authorization > code. > > EHL > > > On 7/13/10 9:11 PM, "Brian Eaton" <bea...@google.com> wrote: > > Draft 10 currently requires that the authorization code issued for the > web-app profile is a single use token. That won't scale well. > > This got added in draft 4, I'm not sure why. Anybody know...? > > Here's the relevant section: > http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-3 > > "The authorization code SHOULD expire shortly after it is issued. The > authorization server MUST invalidate the authorization code after a > single usage." > > I think better language would be something like this: > > "Under normal circumstances, clients will use the authorization code > immediately after receiving a redirect from the Authorization Server. > Authorization codes SHOULD expire shortly after they are issued to > minimize the risk of leaks. Clients MUST NOT reuse verification > codes. Authorization servers MAY make authorization codes single use > tokens. If an Authorization Server detects multiple attempts to > exchange a single verification code for an access token, the > verification code may have leaked. The Authorization Server MAY > revoke all tokens previously issued based on that verification code." > > Justification... > > "Authorization servers MAY make authorization codes single use > tokens": this is not a MUST because single use tokens are expensive > and slow to implement. They require synchronous replication of > server-side state. Because the oauth client and the user who approved > the request may be in geographically distant locations, this is pretty > much guaranteed to be either slow, or unreliable, or both. When > things like immediate mode with automatic authorization are used, lots > and lots verification codes are going to be issued for no good reason. > Server-side storage for those tokens is wasteful, so people are going > to end up using cryptographic implementations of verification codes. > > "The authorization code SHOULD expire shortly after it is issued": > this is a good idea because we are passing authorization tokens via > browser redirects, and browser redirects are leaky channels. If one > of these tokens leaks, someone who captures the token can replay it to > the client web site, and the client web site will then happily swap > the code for an access token. The client web site will then associate > the victim's access token with the attacker's account. > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
