CloudServices/Sagrada/TokenServer: Difference between revisions

Jump to navigation Jump to search

CloudServices/Sagrada/TokenServer (view source)

Revision as of 23:44, 12 January 2012

1,597 bytes removed ,  12 January 2012
no edit summary
No edit summary
Line 49: Line 49:
* '''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)
* '''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.
* '''Auth Token''': used to identify the user after starting a session.  Contains the user application id and the expiration date.
* '''Metadata Token''': used to send application-specific metadata for the Service.
* '''Master Secret''':  a secret shared between Login Server and Service Node. Never used directly, only for deriving other secrets.
* '''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 auth and metadata tokens.
* '''Signing Secret''': derived from the master secret, used to sign the auth token.
* '''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.
* '''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.
* '''AES-CBC''': The symetric block cipher used to encrypt data. The block cipher mode in use is CBC with a random IV.


Some assumptions:
Some assumptions:
Line 111: Line 108:
* the Login Server asks the Users DB if the user is already allocated to a node. [3]
* 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]
* 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]
* 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'' [6]


   HTTP/1.1 200 OK
   HTTP/1.1 200 OK
Line 118: Line 115:
   {'oauth_consumer_key': <auth-token>,
   {'oauth_consumer_key': <auth-token>,
     'oauth_consumer_secret': <token-secret>,
     'oauth_consumer_secret': <token-secret>,
     'service_entry': <node>,
     'service_entry': <node>
    'metadata': <metadata-token>
     }
     }


* the client saves the node location and oauth parameters to use in subsequent requests. [6]
* 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''.
* 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]  


     POST /request HTTP/1.1
     POST /request HTTP/1.1
Line 133: Line 129:
                     oauth_nonce="7d8f3e4a",
                     oauth_nonce="7d8f3e4a",
                     oauth_signature="bYT5CMsGcbgUdFHObYMEfcx6bsw%3D"
                     oauth_signature="bYT5CMsGcbgUdFHObYMEfcx6bsw%3D"
    X-App-Metadata: <metadata-token>


* the node uses the Signing Secret to validate the Auth Token [9].  If invalid or expired then the node returns a 401
* the node uses the Signing Secret to validate the Auth Token [9].  If invalid or expired then the node returns a 401
Line 139: Line 134:
* the node processes the request as defined by the Service [11]
* 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:
A token is a json encoded mapping. The keys of the Authorization Token are:
 
* 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
* '''expires''': an expire timestamp (UTC) defaults to current time + 30 mn
Line 166: Line 153:


'''The authorization token is not encrypted'''
'''The authorization token is not encrypted'''
=== Metadata token (optional) ===
The keys of the Metadata token are free-form. This token can include anything needed by the application to function.
It's passed as-is by the client to the Service Node
Example:
  meta_token = {'email': 'my@email.com', 'someparam': 1324654308.907832} 
To avoid information leakage, the token is encrypted and signed then base64-ed. The encryption is AES-CBC using the encryption key, the signature is HMAC-SHA1 using the signing key:
  meta_token = AES-CBC(meta_token, enc_secret)
  meta_token, signature = HMAC-SHA1(meta_token, sig_secret)
  meta_token = b64encode(meta_token, signature)
'''The metadata token is encrypted'''


== Secrets ==
== Secrets ==
Line 198: Line 166:
(XXX crypto review required, not sure if this is the best/correct way to use HKDF for this purpose)
(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:
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 as follows:


* sig-secret:  HKDF(master-secret, salt=None, info="SIGNING", size=digest-length)
* sig-secret:  HKDF(master-secret, salt=None, info="SIGNING", size=digest-length)
* enc-secret:  HKDF(master-secret, salt=None, info="ENCRYPTION", size=aes-key-length)


By using a no salt (or a fixed salt) these secrets can be calculated once and then used for each request.
By using a no salt (or a fixed salt) these secrets can be calculated once and then used for each request.
Line 306: Line 273:
* '''oauth_consumer_secret''' - a secret derived from the shared secret
* '''oauth_consumer_secret''' - a secret derived from the shared secret
* '''service_entry''': a node url  
* '''service_entry''': a node url  
* '''metadata''': a signed ''and'' encrypted token, containing app-specific metadata - '''optional'''


Example:  
Example:  
Line 317: Line 283:
  'oauth_consumer_secret': <derived-secret>,
  'oauth_consumer_secret': <derived-secret>,
  'service_entry': <node>,
  'service_entry': <node>,
'metadata': <metadata-token>,
}
}
</pre>
</pre>
Tarek.ziade
Confirmed users
927

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/386790"

Navigation menu