Privacy/BestPractices/OAuth: Difference between revisions
< Privacy
Jump to navigation
Jump to search
| Line 5: | Line 5: | ||
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: | 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. | * 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. In this process, the user typically sees, before approving the request, which rights the consumer is requesting (e.g. read, read/write, ...). | ||
* authenticating API calls: the consumer uses credentials to authenticate its API calls against the data host. | * authenticating API calls: the consumer uses credentials to authenticate its API calls against the data host. | ||
OAuth version 1 and 2 are | OAuth version 1 and 2 are quite different, but they both follow the above pattern. | ||
=== Differences between OAuth 1.0 and 2.0 === | === Differences between OAuth 1.0 and 2.0 === | ||
OAuth 1.0 and 2.0 are incompatible at the protocol level. | OAuth 1.0 and 2.0 are incompatible at the protocol level. The important design differences are: | ||
* 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 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. | ||
Revision as of 00:35, 10 May 2011
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. In this process, the user typically sees, before approving the request, which rights the consumer is requesting (e.g. read, read/write, ...).
- authenticating API calls: the consumer uses credentials to authenticate its API calls against the data host.
OAuth version 1 and 2 are quite 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. The important design differences are:
- 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 do not appear to be in use by providers at this point.