Hi Nick,
I'm just now getting back to things after a long weekend.
Typically, you'll just write a small piece of code to encrypt and sign the token and put it into a session cookie. You'll just use a combination of things, somewhat in this order (xslt as an example):
- Create or identify a signing key and an encryption key from a named set of key objects in your system. The signing key should be the name of a crypto key object, whereas the encryption key should be the name of a shared secret key.
- Create a nodeset containing the bearer token and an issuing time (maybe converted to seconds with "date:seconds(date:date-time())". Let's call that nodeset "bearer_token". You could also opt for using an expiring time by using "date:add(date:date-time(), whatever)".
- Create a hash of the token using something like "dp:c14n-hash($bearer_token, false())". Let's call this "hashed_token".
- Create a signature nodeset, say, "signed_token", using something like "dp:sign("algorithm like rsa-sha1", $hashed_token, concat('name:", name_of_signing_key_object))".
- Then create yet another nodeset containing the token and it's signature in two elements. Let's call this nodeset "session_data".
- Encrypt that nodeset into a variable with the encryption key using "dp:encrypt-data("pick appropriate algorithm - see docs", concat("name:", name_of_encryption_key_object), $session_data)". Let's call this variable "cookie_value".
- Finally, set the cookie into the response header with set or append, such as "<dp:append-response-header name="'Set-Cookie'" value="$cookie_value"/>'.
I could say this is possibly a simplified form, as at some point you'll need to decrypt and validate the cookie and check the expiration date against the current time. I also don't know for certain if you're using XSLT, so, the main reason for the xslt-ish pseudo-code.