In a global deployment, when there is a service involved instead of an end-user, there is a chance that the app attempts to create a session and then use it on other nodes BEFORE the replication could catch up.
Instead of storing the sessions in a persistent backend, let's store them on the client side using a different token format, called JWT (Json Web Token).
Q: If the admin comes in and modifies authorization data, how do you make sure that the access is revoked?
A: As long as you have dependency on the data stored on the client side, there is little that can be done (other than ensuring that privilege related data is not stored in the session itself AND that the session itself does not give implicit privileges).
Q: Can the token size grow too big?
A: There are several limitations that needs to be taken into account (header size, browser cookie size limitations, etc). Note that you can't change the contents of the session once it has been issued.
Q: What if the token is being passed around parties? How do you make sure that you are not vulnerable against session hijacking attacks?
A: The same problem exists with stateful sessions as well. Future iterations of stateless session implementations are likely to tackle this problem in some way or another. Also: session quota doesn't work, as the server doesn't keep data about the sessions.
What about logging out sessions?
This is the problem solved by bloom filters.
Logout now just means that you delete the cookie in the browser. What if there is a client that stores the session ID?
The information stored in persistent store is now actually a blacklist of sessions. The blacklist is much less data than the actual session stored previously.
- list of bits
- each of the bits can store 0 or 1
- you can tell whether a session has been certainly not terminated OR you can tell if it might have been terminated
Bitmap result of hash functions executed on the sessions:
- log in A and B (so you have 1010 in your bloomfilter essentially)
- check if D is logged out: 1000 -> maybe your account has logged out
The amount of bits and how many bits can be set by a session (number of hash functions) can be used to tune the probability of false positives (results with might).
At some point the bloom filter no longer usable, and at that point you need to throw it away and start from scratch. For this problem ForgeRock has implemented the rolling bloomfilter, so for example after the full session timeout you could just get rid of the previous bloomfilter and start afresh.
10000 sessions with 1% false positive needs 11.7 kB data, to get 0.01% false positive rate you'll need 23.4kB
Stateless OAuth2 is going to be one of the new features introduced in 13.5. Per spec you can use authorization code once with OAuth2. If you revoke an OAuth2 token, then you can use the bloom filter to verify if the token got revoked.
access_token is now stored in jwt format (introspectable token), so that the RS can decide to validate the access_token on the RS side only (works well with short lived tokens, if there is a need to handle token revocation, you still need to check with the authorization server)
Q: What about UMA related tokens (like RPT)?
A: they are currently not stateless
Q: What if you want to store sensitive information in the session?
A: should encrypt the stateless sessions (but keep in mind the size changes that may impose.