@@ -16,6 +16,7 @@ data in one of the available session storage backends.
17At present the available backends are (as passed to `--session-store-type`):
17At present the available backends are (as passed to `--session-store-type`):
18- [cookie](cookie-storage) (default)
18- [cookie](cookie-storage) (default)
19+- [redis](redis-storage)
20### Cookie Storage
21### Cookie Storage
@@ -32,3 +33,26 @@ The following should be known when using this implementation:
32- Since multiple requests can be made concurrently to the OAuth2 Proxy, this session implementation
33- Since multiple requests can be made concurrently to the OAuth2 Proxy, this session implementation
33cannot lock sessions and while updating and refreshing sessions, there can be conflicts which force
34cannot lock sessions and while updating and refreshing sessions, there can be conflicts which force
34users to re-authenticate
35users to re-authenticate
40+The Redis Storage backend stores sessions, encrypted, in redis. Instead sending all the information
41+back the the client for storage, as in the [Cookie storage](cookie-storage), a ticket is sent back
42+to the user as the cookie value instead.
44+A ticket is composed as the following:
46+`{CookieName}-{ticketID}.{secret}`
50+- The `CookieName` is the OAuth2 cookie name (_oauth2_proxy by default)
51+- The `ticketID` is a 128 bit random number, hex-encoded
52+- The `secret` is a 128 bit random number, base64url encoded (no padding). The secret is unique for every session.
53+- The pair of `{CookieName}-{ticketID}` comprises a ticket handle, and thus, the redis key
54+to which the session is stored. The encoded session is encrypted with the secret and stored
55+in redis via the `SETEX` command.
57+Encrypting every session uniquely protects the refresh/access/id tokens stored in the session from