Back to Labs/Weave.
A key goal of Weave is to enable third party applications to build services that make use of information stored in Weave.
It is a key principle of Weave that users own their data, and have complete control over its use. Users need to explicitly enable third parties to access their data.
Enabling that third party access should not require that users surrender their Weave login credentials to any third party.
This is the problem that OAuth was designed to solve.
Note: Weave is a "service provider" in OAuth parlance. Third-party applications wishing to access service provider data on behalf of a user are called "consumers".
The basic idea of OAuth Authentication is that:
1. The Consumer obtains an unauthorized "Request Token" from the Service Provider. 2. The User authorizes that Request Token with the Service Provider, then indicates to the Consumer that the token is authorized. 3. The Consumer then exchanges that Reqeust Token for an Access Token that it can then use to access the protected resources at the Service Provider.
1. Consumer registers with services.mozilla.com, providing a public RSA key. The consumer is subsequently assigned a consumer key and secret.
2. GET https://services.mozilla.com/api/oauth/request?oauth_consumer_key=key&oauth_signature_method=PLAINTEXT&oauth_signature=sig&oauth_timestamp=time&oauth_nonce=nonce
assigns the consumer an unauthorized request token and secret:
3. Consumer redirects user to https://services.mozilla.com/api/oauth/authorize?oauth_token=req&oauth_callback=foo
The callback is optional, but if it is provided, the user will be redirected to it at the end of the authorization process along with a single GET parameter: oauth_token
Note that the authorization process can only be performed by the user in Firefox with Weave installed.
4. GET https://services.mozilla.com/api/oauth/exchange?oauth_consumer_key=key&oauth_token=req&oauth_signature_method=PLAINTEXT&oauth_timestamp=time&oauth_nonce=nonce
exchanges a (now authorized) request token for an access token.
5. Consumer uses acquired access token to access resources on behalf of the user. The URIs to access data are the same as always, with the exception of the Authorization header which will now contain OAuth parameters instead of HTTP BASIC auth.
In the success case, the flow would bascially be as follows: