668
edits
Privacy/BestPractices/OAuth: Difference between revisions
Jump to navigation
Jump to search
→Overview of OAuth
| (16 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
From time to time, Mozilla products may need to access third-party services protected by OAuth. This document details the options | From time to time, Mozilla products may need to access third-party services protected by OAuth. This document details the software design options against various OAuth providers and catalogs their pros and cons. | ||
== Overview of OAuth == | == Overview of OAuth == | ||
| Line 9: | Line 9: | ||
* 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. | ||
=== Credential Negotiation === | |||
* the consumer registers with the data host and obtains a <tt>consumer_key</tt>, which is considered public, and a <tt>consumer_secret</tt>, which should be kept private. | |||
* a user interacting with a data consumer decides to connect it to her data host, triggering the consumer to redirect the user to the data host with a permission request. | |||
* the user is prompted to approve the request, at which point the data host redirects the user's browser back to the data consumer with a confirmation code. | |||
* the data consumer makes an API call to the data host, authenticated with the consumer's credentials, to exchange the confirmation code for an <tt>access_token</tt> (and, in OAuth 1.0, an <tt>access_token_secret</tt>.) | |||
The resulting access token is the user-specific credential that can be used to make API calls. | |||
=== Authenticating API Calls === | |||
To make OAuth-credentialed API calls, the consumer adds authentication information to the HTTP calls it makes. This authentication information ranges from adding the access token as a GET parameter (OAuth 2.0 bearer tokens), to canonicalizing the request and signing it with HMAC using a combination of the <tt>consumer_secret</tt> and <tt>access_token_secret</tt> (OAuth 1.0 HMAC). | |||
=== Differences between OAuth 1.0 and 2.0 === | === Differences between OAuth 1.0 and 2.0 === | ||
OAuth 1.0 and 2.0 are | 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. | * 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. | ||
| Line 21: | Line 35: | ||
* 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 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 === | === Web-based === | ||
The typical OAuth architecture involves | The typical OAuth architecture involves a web-based consumer 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. | ||
OAuth 1.0 is designed around this specific use case (and makes others difficult). OAuth 2.0 calls this the Authorization Code Flow, because when the user approves the data-access, an authorization code is issued, and the data consumer must exchange this code for the actual access token. | |||
=== Device-based === | === Device-based === | ||
In some cases, e.g. desktop software or mobile-device apps, the consumer is not hosted on a remote server, | 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. Some controls can make it harder to extract the secret, but it is always feasible. | ||
To integrate the desktop/device software with the web-based data host, it is typical for the consumer software to spawn a web browser through which the user authenticates and grants permission. Things are a little bit tricky for the second redirect, from the data host back to the consumer. In some cases, notably mobile devices, apps can register protocol names, so that redirecting to <tt>appname://back_from_auth?code=..</tt> will trigger the switch back to the app, which can then complete the credentialing dance using the obtained code. | |||
OAuth 2.0 defines a more integrated flow called the Implicit Authorization Grant. The data-consumer software is expected to embed a web browser and direct it to the data host for authorization. In the second redirect, the data host sends the consumer's embedded browser to a well-defined URL with the <tt>access_token</tt> positioned in the fragment identifier. The data consumer is expected to sniff this URL, extract the <tt>access_token</tt> and close its embedded web browser. | |||
=== Hybrid === | === Hybrid === | ||
| Line 38: | Line 60: | ||
=== Facebook === | === Facebook === | ||
Facebook supports only OAuth 2.0, with all three flows: server-side, fully device-based, and hybrid. In the device-based mechanism, the <tt>consumer_secret</tt> is not required. Thus, Facebook OAuth flows can be fully implemented in a desktop/mobile client. | |||
=== Twitter === | === Twitter === | ||