That's even worse I think, it's a harder problem. Why do we want to
revoke previously issued tokens here? It closes one door but opens a
DOS attack.
________________________________
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Behalf Of Eran Hammer-Lahav
Sent: Tuesday, July 13, 2010 9:26 PM
To: Brian Eaton; OAuth WG
Subject: Re: [OAUTH-WG] single use authorization codes
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
