An Introduction to OAuth 2.0
OAuth is a protocol that lets applications request data or privileges you have on a remote service without you having to provide your credentials for that service. A classic use case for this “valet key” system is contact import – you can let a site load your address book from Gmail without giving that site your actual Gmail password. Twitter recently required that any third-party applications using their API must authenticate using OAuth.
Twitter’s implementation is based on OAuth 1.0, which was finalized in April but has been in development for several years and is already widely supported. But work on a new version is now under way, and Facebook has already implemented one variety of the draft specification for applications that connect to their service. OAuth 2.0 currently defines specific flows, or client profiles, for handling authentication: Web Server, User-Agent, Native Application, and Autonomous. The first two are most commonly used for web applications, and implementations of the third may end up being quite similar.
The process for most clients involves three broad parts. (Note that “client” in this context refers to the application seeking access, not the person using the application.) The first involves user authentication. For a web-based service, this will often mean ensuring the identified user is currently logged in and then asking for their permission to enable access if they have not previously granted it. Second, the client has to authenticate. In other words, the client making the request has to prove it is the same application that the user granted permissions to in the first step. If both of these steps complete without error, the client is given means to access the protected resources, typically with a temporary code known as an access token.
The specific details of how these steps happen depend on the client profile used. Facebook’s standard Graph API authentication is an example of the Web Server flow. When first requiring access to private user data, a third-party application will forward the user’s browser to Facebook’s authorization server. The request includes a public code identifying the application and a URI under the application’s control. Facebook prompts the user for the permissions and (if they are granted) redirects the browser to the provided URI, along with an authorization code. The client then makes a request directly to Facebook which includes this authorization code and a secret code identifying the client. Facebook then sends back an access token, which is used to authenticate specific access requests for the duration of the session.
The User-Agent profile differs in that it relies on a user-agent’s same-origin policy rather than a client secret for authenticating the client. This process provides OAuth capabilities for JavaScript-based applications that do not have a server-side component and thus cannot ensure identifying codes are kept secret.
Simplicity was a major factor in creating OAuth 2.0, and thus several parts of OAuth 1.0, such as signatures and nonces, no longer apply. However, OAuth 2.0 requires transport-layer security of TLS 1.2 at minimum (as of draft 7) for the interface used to request and receive access tokens. The spec also recommends that secure channels be used for other parts of the process. In Facebook’s implementation, all server interfaces are accessed via HTTPS addresses.
From a security perspective, OAuth is a good step in that it discourages the anti-pattern of one application requesting a user password for another application. It can also protect users in other ways; for instance, if someone intercepted the authorization code for a Facebook application, they would not be able to use it for data access without also obtaining the application’s client secret. However, OAuth only addresses particular issues with third-party access and should not be considered a silver bullet for security. As an example, access by Facebook applications vulnerable to cross-site scripting may still be hijacked once the application has been authorized.
While OAuth 2.0 is still in draft status, Facebook’s deployment makes it in wide use already, and we’ll likely see many more implementations in the months to come. The description above should help you understand the basics of how OAuth 2.0 works, but if you’re interested in further details, check out the full spec and Facebook’s specific authentication guide.