Manu Cohen-Yashar's Blog

4 בפברואר 2014

When ever I introduce OAuth to my clients they ask. “Is it secure? We heard that …”

There is doubt that there is a lot controversy about OAuth yet there is also no doubt that OAuth 2.0 is the leading authorization standard / framework in the web today. Eran Hammer one of OAuth original creators published lots of criticism on the final OAuth 2.0 specification in which he claims that OAuth 2.0 is not a specification but a framework. In his view the spec is not specific enough and leave to much room for variations in the implementations. He also complains about bearer tokens that can be stolen, about the imaginary trust that the client has in its identity provider and about the large attack surface of authorization endpoints and token endpoints.

Eran Hammer has good points, yes OAuth could have been better but still it is possible to use the OAuth framework securely.

When implementing the OAuth 2.0 flow there are few things to keep in mind:

1. Do Strong Validation:There should be strong validation of all incoming parameters involved with the token request flow. Such validation will mitigate threats concerning the attach surface.For example is Facebook would have validated the redirect_uri properly the attack you mentioned here would not be possible.

2. Use SSL only:SSL will mitigate theft of access token in a man in the middle attack.

3. Use OpenIDConnect ID tokens for Authentication instead of OAuth access tokens:ID Tokens are JWT tokens that contains a signature , expiration, subject, issuer, and audience. ID token are produced together with a regular OAuth Access Token but they are specific to a single application. Applications can validate the token, get the user attributes they need (subject) and make sure that the token was created for this specific application by a trusted Authorization Server. This mitigate lots of threats concerns with using a stolen legitimate access token in other applications.

OAuth 2.0 is an authorization protocol but many customers are not using it as such. They are not delegating access to the user’s resources in a resource server. They do not need access to the users friends in Facebook … They only need to use OAuth 2.0 for authentication.

Using OAuth Access Token (that grants access to the UserInfoEndpoint) for authentication is not good enough because if a someone gets hold of this access token they can use it to impersonate the user. This is why we are using OpenID Connect on top of OAuth 2.0 .

The following blog post claims that Access token can be stolen on the user’s agent. In this case SSL\TLS does not help, but it also claims the fact that OpenID connect ID tokens that are created for specific applications mitigate that. “Bottom line, OpenID Connect looks pretty good from the profiling perspective so far”

One last point.

If you are not an expert it is not recommended to implement an OAuth Authorization Endpoint Nor a Token Endpoint. For this you can use commercial product and services such as the Auth0 platform. A safe implementation of OAuth and OpenIdConnect is what they sell.

You can meet with them and verify that their implementation mitigate all the threats as described in the OAuth threat model.