Confirm
471
edits
Changes
m
→Creating a Session
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. The token is consumed even if the request fails (e.g. the MAC did not match).
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.
