Tuesday, April 30, 2013

Which begs the question ....

In YAPAUOFA (Yet Another Post About Using OAuth For Authentication) I argue (following the lead of John and Vittorio) that the issue with trying to use OAuth OOB for authentication is that a Client can use a token it obtains 'fairly' in order to impersonate the corresponding user at some other Client.

Necessarily then, a Client has gone 'bad'.

Why then is this not an issue for the use case that OAuth was designed for, ie delegated authorization of API access? Could not such a Client also go 'bad' and do similarly malicious things?

In the delegated access use case for OAuth, all that an access tokens 'means' is that it allows a Client to access the corresponding User's protected resources. Clearly a Client can go bad and share this access token and (in a bearer token model) anybody else who obtains that token will also be able to access those same resources. Critically, all these additional Clients will only enjoy the permissions allowed by the scope attached to the original token.

As John points out
In the authorization case the client can be trusted with the access token because it has no real motivation to share it.  They could give it to a third party and also grant them access to the information(protected resource), but they can just share the information anyway if they are bad
Yes the Client can go bad and share the access token. But it already has access to the protected resources and can already do all the evil operations it desires against those resources. The fact that a shared token will allow multiple bad Clients to perform evil operations instead of only the original bad Client probably wont matter much to the user.

So in the authorization case, if a Client goes bad - it doesn't really matter whether that evil manifests as that Client doing malicious things with the token, or rather sharing that token and allowing other bad Clients to do the malicious things. Put another way, sharing the token doesn't change the 'scope' of the possible damage.

But this isn't the case when basic OAuth is used for authentication. If a malicious Client can use its own token to impersonate a User at some other (non-evil) Client, then the scope of the attack expands greatly - to include all the damage that malicious Client can do at the other Client.


YAPAUOFA (Yet Another Post About Using OAuth For Authentication)


As both John and Vittorio have written (extensively) on the matter, I will be brief.

The fundamental problem with using OAuth (with no additional constraints) for authentication is that it relies on the following premise

‘If I can enable the delivery of a valid access token to a Client, then I can lay claim to the identity represented by that access token at the corresponding AS.’

So, if an attacker (acting as a normal OAuth Client, albeit one with evil in its heart) can obtain a valid access token for a User Bob from a valid AS, it can present it to a different valid Client and have the following conversation

Attacker->Client: Here is a token
Client->AS: tell me about the User associated with this token
AS->Client: that token is good and refers to Bob
Client to itself: Hmm, well it meets the criteria ……
Client->Attacker: Welcome Bob
Attacker->Client: Err, hi, yes well of course I'm Bob. Let's start moving $$

The core problem is that the valid Client is unable to distinguish between a token previously handed to the Attacker, and a valid token being delivered via the real Bob. 

So why not add something to the token to make that distinction easy for the valid Client, so the conversation now becomes

Attacker->Client: Here is a token
Client to itself: Whoaaa, this token is not for me!!!
Client->Attacker: Nice try bud

That is what OpenID Connect does, the OIDC id_token carries the audience (in the aud param) to which the token was issued, preventing it from being presented elsewhere. If an OIDC Client is presented with an id_token with an audience not itself, it will stop the login process.

Facebook Connect similarly restricts the audience, but does so implicitly by requiring that the Client validate a signature calculated over the signed_request. If a Client can't validate the signature, it will know that something is up and abort.

Persona UX

You start off at the SP

The SP sends you to the IdP (of which there is 1? there was no discovery step)


I am going to log in to Persona.



How long?
 I'm in


New line of greeting cards


Monday, April 15, 2013

The hip bone is connected to the thigh bone ....

The graphic below represents the 'chain of secrets' for OAuth - showing how it is the logical combination of a client & a user (as represented by their secrets) that are combined into OAuth tokens for use on API calls.

After authenticating to an OAuth Authorization Server with it's password (green 'Pwd'), a User grants to a given Client an authorization grant, as manifested in an authorization code (green 'Code').

An OAuth Client exchanges that code for a Refresh Token (Green 'Rt'), using its client secret (red 'Cs') on the request.

The OAuth Client can exchange the refresh token for Access Token (green 'At'), also using its client secret on the request.

The Access Token is then presented by the Client to the REST endpoint (yellow 'API') , as proof that the User has previously made the grant (ie gave their consent).

For native clients, it's unrealistic to expect that the app could be distributed (through an app store) with a secret (such as 'Cs') so instead the app can be distributed with a global Application Secret (red 'As'), this subsequently exchanged for a unique Cs (as in the dynamic registration spec).