Francisco,
the attack you described sounds very similar to session fixation
attacks. TLS (more specifically server authentication) is one way to
cope with spoofing in general (supposed the client has a reasonably CA
policy). So it should do in this case, too.
Validation of the redirect_uri associated with a particular
authorization code on the tokens endpoint is another way to
detect/prevent such an attack. Supposed the attacker has to inject the
tapped authorization code into the client application during a second
authorization flow. If the client uses different redirect_uri's for
every flow, the attempt to inject the code can be detected.
What do you think?
regards,
Torsten.
Torsten,
> you made a good point. However, the question is if this
> belongs into the OAuth scope since this a general attack on
> a web app's session management.
I gave two variants of the attack. I agree that the first
variant "looks like" an attack against session management,
but the second variant is clearly an attack against the
protocol.
Let me recap the second variant.
The attacker compromises the DNS, mapping the domain name in
the redirection URI to the attacker's machine. The http
request sent by the resource owner's browser to the
redirection uri, which contains the authorization code, is
received by the attacker's machine. The attacker forwards
the request with the authorization code to the client
application from the attacker's own machine, thereby
impersonating the resource owner. The client application
mistakenly authenticates the attacker as the resource owner
after verifying that the authorization code is legitimate by
using it to get an access code from the authorization
server. After the mistaken authentication, the client
application creates a session and gives an authentication
cookie to the attacker.
Let me philosophize a bit.
OAuth was conceived as an authorization protocol, hence the
vocabulary ("authorization server", "resource owner"), but
it has morphed. Now it is also used for authentication.
When you click on a button "Login with Twitter" or "Login
with Facebook" you are authenticated with OAuth: Twitter and
Facebook do not currently support OpenID for social login.
When OAuth is used for authentication, the authorization
code takes on a different role: posession of the
authorization code is what authenticates the user.
Therefore transmission of the authorization code must be
protected by TLS.
Let me philosophize some more. (Busy people should stop
reading here ;-)
We need a protocol that does both authentication and
authorization. We can take OAuth and adapt it for
authentication, or take OpenID and adapt it for
authorization, or combine OpenID and OAuth (great solution
for people who love complexity) or... take the best ideas
from OpenID and OAuth and incorporate them into a new
protocol that's designed from the start for both
authentication and authorization. That's one of my
motivations for proposing PKAuth.
Now a political speech.
Social login is going to win. (I use "social login" as
Janrain uses it, I believe they coined the term, is that
right?) It will win because it has tremendous advantages
not just for users (that's not enough), but also for social
sites and applications. Once it wins we may get into a
situation where social login with the social identity
provided by the dominant social site (currently Facebook)
becomes the de fact standard for user authentication on the
Web. If the dominant social site requires application
registration, then every application on the Web will have to
register with the dominant social site just to be able to
authenticate its users, whether or not they have anything to
do with the social site.
The dominant social site would then have to power to kill
any application by terminating its registration. This would
be an intolerable situation for everybody, including the
dominant social site. The dominant social site will not
need or want this kind of power, which would call for
government regulation by every government on the planet.
So we need an authentication and authorization protocol
where application registration is optional. But
registration has an essential function in OAuth. The social
site relies on registration to be able to reliably identify
the application to the user. We need a protocol that can
reliably identify unregistered applications to the user.
That's a second motivation for PKAuth.
Francisco
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
