Privacy/BestPractices/OAuth: Difference between revisions

← Older edit

Privacy/BestPractices/OAuth (view source)

Revision as of 22:09, 27 May 2011

3,127 bytes added , 27 May 2011

→‎Overview of OAuth

BenAdida

668

edits

@@ 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 various OAuth providers and catalogs the pros and cons of these 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 ==
@@ Line 9: / Line 9: @@
 * authenticating API calls: the consumer uses credentials to authenticate its API calls against the data host.
-Though they both follow the above pattern, OAuth 1.0 and 2.0 are quite different.
+=== 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 ===
-OAuth 1.0 and 2.0 are incompatible at the protocol level. The important design differences 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.
@@ 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.
-== Designs of OAuth Consumers ==
+== 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 data host, e.g. Facebook, a web-based consumer, e.g. FarmVille, and a user accessing both services via a typical web browser with no special capabilities. 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.
+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 ===
-In some cases, e.g. desktop software or mobile-device apps, the consumer is not hosted on a remote server, rather it is hosted on each user's device.
+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 ===
@@ Line 38: / Line 60: @@
 === 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 ===