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
