Confirm
471
edits
Changes
m
As before, the respXORkey The authToken is used to encrypt derive four values: * tokenID* reqHMACkey* respHMACkey* respXORkey The client uses tokenID and reqHMACkey for a HAWK (https://github.com/hueniverse/hawk/) request to the concatenated keyFetchToken"POST /session/create" API, using tokenID as "credentials.id" and reqHMACkey as "credentials.key". The server uses tokenID to look up the corresponding token, then derives reqHMACkey to validate the request. The server allocates sessionToken stringand keyFetchToken, concatenates them, encrypts the pair by simply XORing it with the two. This ciphertext is then protected by derived respXORkey, and attaches a MAC, using HMAC-SHA256, keyed by generated with respHMACkey. The MAC is appended to the ciphertext, and the whole encrypted MACed bundle is returned to the client.
→Creating a Session
[[File:PICL-IdPAuth-encrypt-sessionToken.png|Decrypting the sessionToken and keyFetchToken]]
The client recomputes the MAC, compares it (throwing an error if it doesn't match), extracts the ciphertext, XORs it with the derived respXORkey, then splits it into the separate keyFetchToken and sessionToken values.
Each authToken is single-use: once a successful request has been made with it, the authToken and its corresponding ID is removed from the server's memory, and subsequent attempts to use it will return a "no such token" error.
Since the authToken can be used by multiple APIs, the server ought to maintain a table that maps the various flavors of tokenIDs (computed for the different APIs) back to the authToken. When a HAWK request with one of these IDs appears, it should look up the tokenID in the corresponding table, retrieve the authToken, compute the associated values (reqHMACkey, etc), create the response, then delete the entire row.
The server can support multiple sessions per account (typically one per client device, plus perhaps others for account-management portals). There can also be multiple outstanding keyFetchTokens. The sessionToken lasts forever (until revoked by a password change or explicit revocation command). The keyFetchToken lasts 60 seconds.
= Obtaining keys kA and kB =
