CloudServices/Sagrada/TokenServer: Difference between revisions

no edit summary
No edit summary
Line 21: Line 21:
* need support for future developments like bucketed assignment
* need support for future developments like bucketed assignment
* Needs to be a system that scales infinitely.
* Needs to be a system that scales infinitely.
= APIS v1.0 =
'''Unless stated otherwise, all APIs are using application/json for the requests and responses content types.'''
== GET /1.0/<app_name>/token ==
Asks for new token given some credentials in the Authorization header.
By default, the authentication scheme is Browser ID but other schemes can potentially be used if supported by the login server. '''app_name''' is the name of the application to access, like '''sync'''.
Example for Browser-Id:
 
<pre>
GET /1.0/sync/token
Host: token.services.mozilla.com
Content-Type: application/json
Authorization: Browser-ID <assertion>
</pre>
This API returns several values in a json mapping:
* '''oauth_consumer_key''' - a signed authorization token, containing the user's id and expiration
* '''oauth_consumer_secret''' - a secret derived from the shared secret
* '''service_entry''': a node url
Example:
<pre>
HTTP/1.1 200 OK
Content-Type: application/json
{'oauth_consumer_key': <token>,
'oauth_consumer_secret': <derived-secret>,
'service_entry': <node>,
}
</pre>
All errors are also returned as json responses, following the structure described in Cornice.
XXX need to document this in Cornice
Status codes and error codes:
* 404 : unknown URL (0), or unsupported application (1).
* 400 : malformed request - missing option or bad values(2) or malformed json (3) or unsupported authentication protocol (4)
* 401 : authentication failed or protocol not supported (5). The response in that case will contain WWW-Authenticate headers (one per supported scheme)
* 405 : unsupported method (6)
* 406 : unacceptable - the client asked for an Accept we don't support (7)
* 503 : service unavailable (ldap or snode backends may be down) (8)


= Proposed Design =
= Proposed Design =
Line 251: Line 301:
# the server process the request [Sync = I/O Bound]
# the server process the request [Sync = I/O Bound]


= APIS v1.0 =
'''Unless stated otherwise, all APIs are using application/json for the requests and responses content types.'''
== GET /1.0/<app_name>/token ==
Asks for new token given some credentials in the Authorization header.
By default, the authentication scheme is Browser ID but other schemes can potentially be used if supported by the login server. '''app_name''' is the name of the application to access, like '''sync'''.
Example for Browser-Id:
 
<pre>
GET /1.0/sync/token
Host: token.services.mozilla.com
Content-Type: application/json
Authorization: Browser-ID <assertion>
</pre>
This API returns several values in a json mapping:
* '''oauth_consumer_key''' - a signed authorization token, containing the user's id and expiration
* '''oauth_consumer_secret''' - a secret derived from the shared secret
* '''service_entry''': a node url
Example:
<pre>
HTTP/1.1 200 OK
Content-Type: application/json
{'oauth_consumer_key': <token>,
'oauth_consumer_secret': <derived-secret>,
'service_entry': <node>,
}
</pre>
All errors are also returned as json responses, following the structure described in Cornice.
XXX need to document this in Cornice
Status codes and error codes:
* 404 : unknown URL (0), or unsupported application (1).
* 400 : malformed request - missing option or bad values(2) or malformed json (3) or unsupported authentication protocol (4)
* 401 : authentication failed or protocol not supported (5). The response in that case will contain WWW-Authenticate headers (one per supported scheme)
* 405 : unsupported method (6)
* 406 : unacceptable - the client asked for an Accept we don't support (7)
* 503 : service unavailable (ldap or snode backends may be down) (8)


= Phase 1 =
= Phase 1 =
Confirmed users
927

edits