Managing OAuth Risks in Mobile Applications
When, not if, endpoints get compromised OAuth tokens and other credentials become collateral damage. That means cyber-attackers may also compromise any resources available through OAuth 2.0, such as accounts at sites accessed through some social login systems or (potentially) HIPAA-protected information accessed through proposed OAuth profiles.
That’s why the discussion that I had with Dick Hardt (the lead OAuth 2.0 editor) and other attendees at an Internet Identity Workshop (IIW) unconference session on “OAuth 2.0 Assurance” was so important. At the panel, it quickly became apparent that OAuth risks for mobile applications were top of mind for attendees.
The debate began when Hardt said “Don’t use the implicit flow.” Per RFC 6749, unlike OAuth 2.0’s Authorization Grant flow, the implicit grant is a simplified interaction optimized for simple clients. “Instead of issuing the client an authorization code, the client is issued an access token directly…no intermediate credentials (such as an authorization code) are issued [and] the authorization server does not authenticate the client.”
Despite the weakness of the implicit flow, many developers use it, which may be why Hardt’s alternative proposal was controversial. Basically, Hardt recommends that the mobile app developers separate the OAuth client into one part that runs on the device and another part that runs on an application server. The application server would use the authorization grant flow and get access tokens down to the client. Also, its important to note that each user/device will get a unique access token.
But – The counter-argument raised against this is that breaking the OAuth client component into two parts like this doesn’t mitigate the risk because “the application can’t authenticate the client anyway.“ By this, I think the attendees meant that they couldn’t verify the device wasn’t compromised.
Let’s cut through the smoke. My own opinion is that endpoint devices will get compromised fairly often and there’s no absolute assurance at the endpoint level. There will be cases where the server part of an application can’t authenticate that an endpoint is “clean.” The whole issue boils down to whether a compromise of a single endpoint reveals just a per-application-instance credential, or whether it reveals a credential intended for all instances of the application. In other words, the only important question is whether a cyber-attack on a single mobile device can compromise just that single user’s resources, or whether it can also compromises the resources of all other users of the application.
The RFC does speak to this issue: “A client may be implemented…with both a confidential server-based component and a public browser-based component. If the authorization server does not provide support for such clients or does not provide guidance with regard to their registration, the client SHOULD register each component as a separate client.”
Bottom line: Its about the registration more than the flow. First, we must prevent cyber-attackers from registering to access another user’s resource and work is ongoing in the OAuth standards community on registration measures, which are currently out of scope for OAuth 2.0. Hardt’s recommendation may be focused on mitigating an even greater risk that an application using a single “cllient id” and “client secret” for all its instances (or devices) could be compromised en masse. Regardless of whether you use the implicit grant or the authorization grant flow mass compromise must be avoided. Global application secrets should not be exposed on a device. Thoughts?