OAuth 2.0 Assurance Issues
In a previous post, “REST Uneasy: Do we need to Worry about OAuth 2.0?” I raised a question which I’ll now attempt to answer in some detail.
The OAuth 2.0 protocol is designed to improve security in scenarios where, without it, multiple web sites such as Facebook and Flickr would have no alternative to password synchronization for federating, or linking their users’ accounts to make the services work together. Give OAuth 1.0 and 2.0 credit where credit’s due for, as some say, reducing the password sharing anti-pattern.
But from another perspective, OAuth has enabled a vast and still-growing amount of data sharing under pretty loose security mechanisms, and this raises risks. The authors of OAuth 2.0 created a standard that works for multiple client configurations and supports use cases ranging from the relatively secure trusted client capable of protecting client credentials and maintaining TLS 1.2 sessions to the much less secure multiuser public client that can’t protect the user’s credentials or applications that don’t support TLS. To handle the less secure use cases, the standards group created a number of low assurance variations on the protocol.
Before we zoom down on the problems, let’s consider the threat model (RFC 6819 doesn’t pull any punches.)
“It is assumed that the attacker has full access to the network between the client and authorization servers and the client and the resource server, respectively. The attacker may eavesdrop on any communications between those parties…” Also “an attacker has unlimited resources to mount an attack” and “two of the three parties involved in the OAuth protocol may collude to mount an attack against the 3rd party.”
All it takes for those assumptions to come true is for an attacker to compromise some PCs, devices and/or network or security infrastructure components. We know this hjappens all the time. Once the attacker has a foothold, OAuth 2.0 gives him or her plenty of opportunities. In light of a real and present threat, then, consider these quotes from the specifications:
“When issuing an access token during the implicit grant flow, the authorization server does not authenticate the client.” Note: attacker may impersonate the client.
“The resource owner password credentials (i.e., username and password) can be used directly as an authorization grant to obtain an access token.” Note: exposes credentials.
“Including the client credentials in the request-body using the two parameters…SHOULD be limited to clients unable to directly utilize the HTTP Basic authentication scheme.” Note: exposes credentials.
“Using a bearer token (RFC 2750) does not require a bearer to prove possession of cryptographic key material.” Note: the bearer token is the only widely available option.
Despite “security weaknesses associated with the URI method…including the high likelihood that the URL containing the access token will be logged…resource servers MAY support this method.” Note: access token exposed in the URL query string.
“This specification does not mandate the use of TLS because at the time of this writing, requiring clients to deploy TLS is a significant hurdle for many client developers.” Note: TLS is recommended, not required.
“Lack of a redirection URI registration requirement can enable an attacker to use the authorization endpoint.” Note: attacker may redirect flows a device it controls.
“The client SHOULD NOT include any third-party scripts (e.g., third-party analytics, social plug-ins, ad networks) in the redirection endpoint response.” Note: but not required, providing opportunities for malware.
“The state parameter SHOULD be used to prevent cross site request forgery cross-site request forgery.” Note: again, but not required.
When you read all this, OAuth 2.0 seems like a pretty low assurance protocol. To close obvious and easily exploitable holes, implementors would have to minimize the use of insecure flows. Where insecure flows have to be used, implementations would have to employ security features such as redirection site pre-registration, token refreshes and state checking. The good news is that the RFCs describe what implementors SHOULD do in great detail.
Unfortunately, OAuth 2.0 specifies no conformance requirements that would compel implementors to follow good security practices. When the rubber meets the road with actual implementations will all the RFCs’ advice – good as it is – actually protect customers or should the industry do something more? Should OAuth 2.0 assurance evaluation guidelines, conformance profiles, testing tools and more mitigations be developed?
The answer to these question is the same as for many in security: it depends on the risk level. OAuth 2.0 may be fine out of the box for sharing photographs, but not for sharing financial or medical records, for example. When it comes to sharing personally identifiable information (PII) risks to the individual may seem low, but compliance risks to web site or ecommerce operators may be higher.
If nothing else, I hope I’ve convinced you that the discussion on OAuth security shouldn’t end with gratuitous advice in the RFCs. What do you think? How real are these risks and where should the bar be for using OAuth 2.0 without extensive additional mitigation?
Related posts