After two fixes, OAuth standard deemed secure

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.

“The OAuth 2.0 authorization framework defines a web-based protocol that allows a user to grant web sites access to her resources (data or services) at other web sites (authorization). The former web sites are called relying parties (RP) and the latter are called identity providers (IdP),” the researchers explained.

“In practice, OAuth 2.0 is often used for authentication as well. That is, a user can log in at an RP using her identity managed by an IdP (single sign-on, SSO).”

The first attack they discovered is made possible when an identity provider uses the wrong HTTP redirection status code when the user logs in.

The attack scenario goes like this: the user uses OAuth to log in to a malicious relying party run by the attacker, and is redirected to the identity provider, where he is asked to enter his credentials.

The credentials are sent to the identity provider via a POST request, checked, and the user is redirected to the relying party’s redirection endpoint. If the identity provider uses the 307 HTTP redirection status code, the malicious relying party (i.e. the attacker) will also receive a POST request containing all the form data in the previous one. This includes the user’s credentials.

The second attack has been dubbed “identity provider mix-up”, and here is why:

“To launch the attack, the attacker manipulates the first request of the user such that the RP thinks that the user wants to use an identity managed by an IdP of the attacker while the user instead wishes to use her identity managed by an honest IdP. As a result, the RP sends the authorization code or the access token (depending on the OAuth mode) issued by the honest IdP to the attacker, who then can use these values to login at the RP under the user’s identity (managed by the honest IdP) or access the user’s protected resources at the honest IdP.”

The attacker must be able to manipulate the various request sent by the user and the responses, meaning the attacker must have a presence on the network (Man-in-the-Middle).

Both attacks can also be mounted against OpenID Connect, which is an authentication layer built on top of OAuth 2.0.

The good news is that both these attacks can be prevented by making relatively simple fixes, and that the working groups for OAuth and OpenID Connect already decided to implement the ones proposed by the group.

With these problems solved, the researchers ultimately concluded that OAuth 2.0 is secure enough to provide both authorization and authentication – if implemented correctly.