Confirm
927
edits
Changes
no edit summary
* '''Two-Legged OAuth''': an authentication scheme for HTTP requests, based on a HMAC signature over the request metadata. (http://tools.ietf.org/html/rfc5849#section-3)
* '''Auth Token''': used to identify the user after starting a session. Contains the user application id and the expiration date.
* '''Master Secret''': a secret shared between Login Server and Service Node. Never used directly, only for deriving other secrets.
* '''Signing Secret''': derived from the master secret, used to sign the auth and metadata tokens.* '''Encryption Secret''': derived from the master secret, used to encrypt the metadata token.
* '''Token Secret''': derived from the master secret and auth token, used as '''oauth_consumer_secret'''. This is the only secret shared with the client and is different for each auth token.
Some assumptions:
* the Login Server asks the Users DB if the user is already allocated to a node. [3]
* if the user is not allocated to a node, the Login Server asks a new one to the Node Assignment Server [4]
* the Login Server creates a response with an auth token and corresponding token secret [5] and sends it back to the user. The auth token contains the user id and a timestamp, and is signed using the signing secret. The token secret is derived from the master secret and auth token using HKDF. It also adds the node url in the response under ''service_entry'', and optionaly a metadata token under ''metadata''. [6]
HTTP/1.1 200 OK
{'oauth_consumer_key': <auth-token>,
'oauth_consumer_secret': <token-secret>,
'service_entry': <node>, 'metadata': <metadata-token>
}
* the client saves the node location and oauth parameters to use in subsequent requests. [6]
* for each subsequent request to the Service, the client calculates a special Authorization header using two-legged OAuth [7] and sends the request to the allocated node location [8] along with the metadata token if provided, in an ''X-App-Metadata''.
POST /request HTTP/1.1
oauth_nonce="7d8f3e4a",
oauth_signature="bYT5CMsGcbgUdFHObYMEfcx6bsw%3D"
* the node uses the Signing Secret to validate the Auth Token [9]. If invalid or expired then the node returns a 401
* the node processes the request as defined by the Service [11]
== Tokens Authorization token ==
A token is a json encoded mapping. The are two tokens: * the authorization token: contains the user application id and the expiration date.* the metadata token: contains app-specific data ''(optional)'' === Authorization Token === The keys of the Authorization Token are:
* '''expires''': an expire timestamp (UTC) defaults to current time + 30 mn
'''The authorization token is not encrypted'''
== Secrets ==
(XXX crypto review required, not sure if this is the best/correct way to use HKDF for this purpose)
The Master Secret is used to derive keys for various cryptographic routines. At startup time, the Login Server and Node should pre-calculate and cache the signing key and encryption key as follows:
* sig-secret: HKDF(master-secret, salt=None, info="SIGNING", size=digest-length)
By using a no salt (or a fixed salt) these secrets can be calculated once and then used for each request.
* '''oauth_consumer_secret''' - a secret derived from the shared secret
* '''service_entry''': a node url
Example:
'oauth_consumer_secret': <derived-secret>,
'service_entry': <node>,
}
</pre>
