668
edits
Privacy/BestPractices/OAuth: Difference between revisions
→Overview of OAuth
| (7 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. | * 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. | ||
| Line 23: | Line 21: | ||
The resulting access token is the user-specific credential that can be used to make API calls. | 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). | 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). | ||
| Line 43: | Line 41: | ||
=== Web-based === | === Web-based === | ||
The typical OAuth architecture involves a web-based consumer | 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. 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. | 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 56: | 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 === | ||