Privacy/BestPractices/OAuth

From time to time, Mozilla products may need to access third-party services protected by OAuth. This document details the options from various OAuth providers and catalogs the pros and cons of these options.

Overview of OAuth

It is often important for users to give a third party access to their data. OAuth is a widely deployed standard for this purpose: a data host, e.g. Facebook, allows a consumer, e.g. FarmVille, to access a user's data when that user agrees. The OAuth protocol consists of two major portions:

• credential negotiation: the consumer, data host, and user engage in a dance that concludes with the consumer obtaining credentials that will allow it to make API calls into the data host to access the user's data. In this process, the user typically sees, before approving the request, which rights the data consumer is requesting (e.g. read, read/write, ...).

• authenticating API calls: the consumer uses credentials to authenticate its API calls against the data host.

Central OAuth Pattern

The most common OAuth pattern, in both OAuth 1.0 and 2.0, works as follows:

• the consumer registers with the data host and obtains a consumer_key, which is considered public, and a consumer_secret, which should be kept private.

• Establishing Credentials:
  • a user interacting with a data consumer decides to connect it to her data host.
  • the consumer

• Making API Calls:
  • foo

Differences between OAuth 1.0 and 2.0

Though they both follow the above pattern, OAuth 1.0 and 2.0 are quite different:

• In OAuth 1.0, API call authentication requires both the user-specific secret and the data-consumer secret. In OAuth 2.0, only the user-specific secret is needed to authenticate API calls.

• OAuth 1.0 is optimized for using HMAC to establish tokens credentials and make API calls, while OAuth 2.0 is optimized for bearer tokens over SSL (essentially, passwords over an encrypted channel.) OAuth 1.0 is technically capable of bearer tokens, but no one uses this because it would require sending the master-secret in every call. RSA signatures can be used in OAuth 1.0 instead of HMAC, but few providers support it, and the option has gone away in OAuth 2.0. HMAC signatures of API calls are supported in OAuth 2.0 with a simplified canonicalization algorithm, but do not appear to be in use by providers at this point (May 2011).

• OAuth 1.0 encourages the use of long-lasting user tokens, while OAuth 2.0 encourages the use of short-term user tokens with a built-in refresh mechanism. The refresh mechanism in OAuth 2.0 requires the consumer's master secret.

OAuth Consumer Design

While data hosts that offer OAuth are consistently web-based services, e.g. Facebook, consumers of OAuth services vary, and this variation can affect the preferable OAuth implementation path.

Web-based

The typical OAuth architecture involves a web-based consumer, e.g. FarmVille, and a user accessing both the data-host and the consumer services via a typical web browser. The most important property of this setup is that the consumer sits on a controlled server and can easily maintain the secrecy of its authentication credentials.

Device-based

In some cases, e.g. desktop software or mobile-device apps, the consumer is not hosted on a remote server. Instead, it runs entirely on each user's device. In this scenario, it is not possible for the data host to truly authenticate the consumer: an attacker can extract all secrets from the software binary. Closed-source software distributed in a tightly controlled environment, e.g. iOS apps, have an inherent advantage here if they wish to keep secret credentials: though it is still possible to extract secret credentials, it's a good bit more difficult.

Hybrid

With OAuth 2.0, because API calls do not require the use of the consumer's master secret, a hybrid approach is possible: the credential negotiation and token refresh are mediated by a web-based server, while the user token remain on the user's device and the API calls are made directly from there.

Major OAuth Providers

Twitter

Twitter runs an OAuth 1.0a service, with tokens that can either read or read-and-write. OAuth 2.0 support is not available at this time.

Twitter is particularly concerned about attackers using OAuth to bypass Twitter rate limits on API calls. Specifically, since rate limits are per-user-per-OAuth-app, leaking the consumer secret means an attacker can use it to increase his number of calls. To our knowledge, this concern is unique to Twitter.