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 in the consumer obtaining credentials that will allow it to make API calls into the data host to access the user's data. This dance involves the user and importantly notifies the user of which rights to her data she is granting the consumer.

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

OAuth version 1 and 2 are importantly different, but they both follow the above pattern.

Differences between OAuth 1.0 and 2.0

OAuth 1.0 and 2.0 are incompatible at the protocol level. In addition, there are important design differences:

• OAuth 1.0 credentials for API calls include the consumer's master secret in addition to the user-specific secret, while OAuth 2.0 credentials for API calls require only the user-specific secret.

• OAuth 1.0 was optimized for token establishment and API-call authentication by HMAC, while OAuth 2.0 is optimized for authentication by bearer tokens over SSL. Both are capable of bearer tokens, but OAuth 1.0's master-secret-in-every-call requirement makes that awkward. RSA signatures can be used in OAuth 1.0, but are not supported in 2.0. HMAC signatures of API calls are supported in OAuth 2.0 with a greatly simplified canonicalization algorithm, but does not appear to be in use by providers at this point.