Is OAuth 2.0 Bad for the Web?

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

Composite Applications went from being a curiosity to mainstream in less than 5 years. One of the key architectural issues when building composite applications is the double authentication that is required to access a particular service and the corresponding authorization rules: in general we need to authenticate both the (composite) application invoking the service and the user of the composite application itself while having the ability to define the service access rules both for the application and the user. This is particularly difficult in a client/server middleware environment, including HTTP, which has been built for decades on the premise that the "client" represents a single identity: either a software client or a user but not both.

It looks that for once the industry has developed a broad consensus to solve an important problem. Yet, Eran Hammer-Lahav, published some criticisms about the latest direction of the specification which dropped signatures and cryptography in favor of "bearer tokens". However, to Eran's own admission,"Cryptography is unforgiving". Developers can easily make mistakes in the steps they take to encrypt or sign a message and it is generally unforgiving. The idea of dropping cryptography was part of the WRAP initiative:

At the heart of the WRAP architecture is the requirement to remove any cryptography from the client side. The WRAP authors observed how developers struggled with OAuth 1.0 signatures and their conclusion was that the solution is to drop signatures completely. Instead, they decided to rely on a proven and widely available technology: HTTPS (or more accurately, SSL/TLS). Why bother with signatures if instead the developer can add a single character to their request (turning it from http:// to https://) and protect the secret from an eavesdropper. Much of the criticism that followed focused on the fact that WRAP does not actually require HTTPS. It simply makes it an option. This use of tokens without a secret or other verification mechanism is called a bearer token [which is very similar to a cookie]. Whoever holds the token gains access. If you are an attacker, you just need to get hold of this simple string and you are good to go. No signatures, calculations, reverse engineering, or other such efforts required.

The argument of the supporters of this model is as follows: since most services use a cookie-based authentication system, it would not be more secure to use additional mechanisms since an attacker would always target the weakest point. Actually, Eran's concerns are not about OAuth today, but the impact that this specification will have in five years when inherently more secure protocol will be needed. First, the argument will again be, since OAuth 2.0 is the weakest point, there is no need to implement stronger security mechanisms. Second, the reason why OAuth would work in today's environment is because all the APIs are fairly significant to the clients and most of the API endpoints are declared statically in the clients code or configuration while being thoroughly tested before the application is released. So overall, there is little risk that the token will be sent to an unfriendly destination.

Yet, Eran believes that the Web needs to be more secure to support more dynamic scenarios and a world of standard APIs implemented by a variety of services:

As soon as we try to introduce discovery or interoperable APIs across services, OAuth 2.0 fails. Because it lacks cryptographic protection of the tokens (there are no token secrets), the client has to figure out where it is safe to send tokens. OAuth reliance on the cookie model requires the same solution – making the client apply the security policy and figure out which servers to share its tokens with. The resource servers, of course, can ask for tokens issued by any authorization server. For example, a protected resource can claim that it requires an OAuth access token issued by Google when in fact, it has nothing to do with Google (ever though it might be a Google subdomain). The client will have to figure out if the server is authorized to see its Google access token. Cookies have rules regarding which cookie is shared with which server. But because these rules are enforced by the client, there is a long history of security failures due to incorrect sharing of cookies. The same applies to OAuth 2.0.

He concludes:

Any solution based on client side enforcement of a security policy is broken and will fail. OAuth 1.0 solves this by supporting signatures. If a client sends a request to the wrong server, nothing bad happens because the evil server has no way of using that misguided request to do anything else. If a client sends an OAuth 2.0 request to the wrong server (found via discovery), that server can now access the user’s resources freely as long as the token is valid.
Without discovery, smaller companies will have a harder time getting their services accessible.

Composite Applications are rapidly becoming a key vector of innovation adding value to otherwise plain data like tasks, friends or TV guides. At the same time, OAuth is poised for a rapid adoption because it solves an acute problem and has gained some momentum in the industry with the support of Facebook, Twitter.... Like often in the standardization process, we are now at crossroads, and our industry has to choose one path or the other: do we support simpler security mechanisms to allow a larger group of developers to build these composite applications, or do we implement stronger ones that would allow other developers to build mores services that interoperate and compete with existing ones? Where do you stand?

You should read my posts more carefully. I am not leaving the OAuth working group, and am determined to see signatures back in the core OAuth 2.0 specification. While I am moving away from open standards, I am planning to stay as involved and lead OAuth for a long time.

Also, its pretty sad I have to register for an account to post a comment.

Does the removal of signatures really mean less security?
by
Yaron Goland

I examined the the impact of removing signatures on OAuth security here and as far as I can tell one can meet all relevant security requirements including replay attack resistance in discovery based scenarios using bearer tokens. So the assertion that we must trade off between ease of use and security does not appear to be true. At least for the attacks so far muted.

I would encourage interested readers to follow the OAuth Mailing List where the issue is now being discussed.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.