Services/F1/Server/API: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with "'''Share Server API''' Security The servers do not store any user account information, the service stores all important user data on the client. All API endpoints MUST be prov...")
 
No edit summary
Line 1: Line 1:
'''Share Server API'''
== '''Share Server API''' ==


Security
=== Security ===


The servers do not store any user account information, the service stores all important user data on the client. All API endpoints MUST be provided ONLY over SSL. User account data sent for each API call in the clear, depending on SSL for security and privacy.
The servers do not store any user account information, the service stores all important user data on the client. All API endpoints MUST be provided ONLY over SSL. User account data sent for each API call in the clear, depending on SSL for security and privacy.  


=== Share Authorization  ===


Share Authorization
The Share Authorization is essentially an authorization proxy supporting OpenID+OAuth, OAuth 1 and OAuth 2. All authorization data is returned to and stored on the client.


The Share Authorization is essentially an authorization proxy supporting OpenID+OAuth, OAuth 1 and OAuth 2. All authorization data is returned to and stored on the client.
==== POST /authorize ====


POST /authorize
Initiates the OAuth dance for a given OAuth provider. The browser will be redirected to the OAuth endpoint for the service, providing a return url pointing to the verify endpoint described below.


Initiates the OAuth dance for a given OAuth provider.  The browser will be redirected to the OAuth endpoint for the service, providing a return url pointing to the verify endpoint described below. 
Post Data:


Post Data:
domain: google.com


domain: google.com
Success Result


Success Result
Upon a successful authorization the OAuth providers redirect back to the verify endpoint, using GET or POST depending on the service implementation.


Upon a successful authorization the OAuth providers redirect back to the verify endpoint, using  GET or POST depending on the service implementation.
Error Result


Error Result
If the user cancels the authorization, we cannot depend upon a redirect back to the f1 server; some services do, others do not.


If the user cancels the authorization, we cannot depend upon a redirect back to the f1 server; some services do, others do not.
==== GET|POST /verify  ====


For a successful authorization, the verify endpoint will create a temporary cookie (account_tokens) to pass the users OAuth tokens back to the client. The client MUST delete this cookie after retrieving the account data. This account data also contains a POCO formatted profile object for the user that is retrieved from that service. The endpoint then redirects to the configured success or error url.


GET|POST /verify
=== OAuth APIs ===
 
For a successful authorization, the verify endpoint will create a temporary cookie (account_tokens) to pass the users OAuth tokens back to the client. The client MUST delete this cookie after retrieving the account data.  This account data also contains a POCO formatted profile object for the user that is retrieved from that service.  The endpoint then redirects to the configured success or error url.
 
OAuth APIs


All APIs require POST and part of the post data must be the account object that was received via the account_tokens cookie (see the verify endpoint above).
All APIs require POST and part of the post data must be the account object that was received via the account_tokens cookie (see the verify endpoint above).

Revision as of 20:51, 18 March 2011

Share Server API

Security

The servers do not store any user account information, the service stores all important user data on the client. All API endpoints MUST be provided ONLY over SSL. User account data sent for each API call in the clear, depending on SSL for security and privacy.

Share Authorization

The Share Authorization is essentially an authorization proxy supporting OpenID+OAuth, OAuth 1 and OAuth 2. All authorization data is returned to and stored on the client.

POST /authorize

Initiates the OAuth dance for a given OAuth provider. The browser will be redirected to the OAuth endpoint for the service, providing a return url pointing to the verify endpoint described below.

Post Data:

domain: google.com

Success Result

Upon a successful authorization the OAuth providers redirect back to the verify endpoint, using GET or POST depending on the service implementation.

Error Result

If the user cancels the authorization, we cannot depend upon a redirect back to the f1 server; some services do, others do not.

GET|POST /verify

For a successful authorization, the verify endpoint will create a temporary cookie (account_tokens) to pass the users OAuth tokens back to the client. The client MUST delete this cookie after retrieving the account data. This account data also contains a POCO formatted profile object for the user that is retrieved from that service. The endpoint then redirects to the configured success or error url.

OAuth APIs

All APIs require POST and part of the post data must be the account object that was received via the account_tokens cookie (see the verify endpoint above).