After Two Fixes, OAuth Standard Deemed Secure (net-security.org)

An anonymous reader writes: OAuth 2.0 is one of the most used single sign-on systems on the web: it is used by Facebook, Google, Microsoft, GitHub and other big Internet companies. A group of researchers from University of Trier, Germany, have performed the first formal security analysis of the OAuth 2.0 standard, and have discovered two previously unknown attacks that could be mounted to break authorization and authentication in OAuth. However, says the article, "[w]ith these problems solved, the researchers ultimately concluded that OAuth 2.0 is secure enough to provide both authorization and authentication -- if implemented correctly."

Comments

Client credentials are a roadblock

[tepples]

The requirement for client credentials in implementations of OAuth produces a couple practical problems.

OAuth 1 and OAuth 2 are unrelated protocols with similar names. The spec for each discourages servers from requiring client credentials (a client ID and client secret) in an API intended for use in an app that runs on the user's computer, such as a desktop or mobile app. As stated in section 4.6 of the OAuth 1 RFC:

In many cases, the client application will be under the control of
potentially untrusted parties. For example, if the client is a
desktop application with freely available source code or an
executable binary, an attacker may be able to download a copy for
analysis. In such cases, attackers will be able to recover the
client credentials.

Likewise section 9 of the OAuth 2 RFC:

Native applications that use the authorization code grant type
SHOULD do so without using client credentials, due to the native
application's inability to keep client credentials confidential.

And the article "OAuth 2 Simplified" by Aaron Parecki states:

If a deployed app cannot keep the secret confidential, such as Javascript or native apps, then the secret is not used.
[...]
mobile apps must also use an OAuth flow that does not require a client secret.

Yet several service providers offering APIs built on OAuth 1 or OAuth 2, notably Twitter, require them. Despite it being trivial to pull client credentials out of an executable with tools such as strings, Twitter has been known to disable any client credentials that leak to the public. There are two workarounds, both cumbersome:

• The first, recommended by OAuth 1 spec author Dick Hardt, is to proxy all API calls through a server that the app developer operates. The API keys then never leave this server. Yet the app developer needs to find some way to recover the cost of operating this proxy server.
• The other, as recommended by Raffi Krikorian and Chris Steipp, requires each user to register with the service provider as a developer, obtain API credentials through the developer console, and enter those into the user's own copy of the application. Because providers tend to refuse to offer a means of automating application registration, each application has to include a walkthrough for registering a copy of an application and update this walkthrough whenever the service provider changes the design of the developer console. In addition, developer consoles tend to require a minimum age of 18 to rather than 13.

OpenID 2.0, an authentication protocol, did not require relying parties to obtain client credentials. It was intended that a user would paste his identifier URI into a form on the relying party's web site (or use a browser extension to autofill it), and the user would be briefly redirected to the identity provider's web site for verification. Very few identity providers required relying parties to register; the only one I could think of was PayPal.

But unlike OpenID 2.0, which was open by default, the OAuth 2-based OpenID Connect is closed by default. It requires each relying party to obtain client credentials from each identity provider's developer console, which requires O(n^2) contract executions. There's theoretically a way for a relying party to obtain client credentials automatically, called Dynamic Client Registration (dyn-reg), but to my knowledge

Re:Summary wrong, not secure

[WoOS]

No, the first attack assumes the identity provider to use an 307 request in answering a valid used identification request from the malicious server (which might look to the outside as a normal service while secretly retrieving user password). As far as I understand the forward will always happen in the protocol. The assumption is that this is done with a 307 request instead of 302 (or 303). This was apparently allowed by the OAuth specification (although one can of course wonder why any ID provider would not use 302 or 303).

Reading the original paper (and not just the blog) really helps to understand the attacks. With respect to the second attack I immediately thought that it wasn't worse than any authentication not using HTTPS. But the authors point out that they attack a step of the protocol (selection of ID provider) not normally considered sensitive so it could happen in HTTP.