Skip to main content

Stateless Tokens within OpenAM 13.0

The unstable OpenAM nightly build of 13.0, contains a great new feature: the ability to create stateless or client side tokens.  This brings a range of new use cases to the access management table, including increased scale (less server side storage, CTS replication and in memory storage) and the potential for "offline" token introspection for authorization.  Stateless does of course lack a lot of the key features of the stateful architecture.

What is a stateless token?

The stateless token is basically a JWT token, that is stored in the existing iPlanetDirectoryPro cookie (if accessing via a browser) or within the tokenId response if authenticating over REST.  The JWT contains all of the content that would stored on the server side in a stateful session - so things like uid, expiryTime and any other profile or session attributes you want to define.

To quote my colleague Ashley Stevenson "Stateful is a phone call and Stateless is a text message".

The token can also be signed and/or encrypted using standard algorithms such as HS256 (which uses a shared secret) or RS256 (which uses a public / private key combo) so adding a bit of security.

Config can be done at the realm level too, which makes for a flexible approach to which realms, users and applications should use it.

Offline Authentication

An interesting bi-product of using stateless tokens, is that introspection can be done on the token, without going back to the originating source - ie OpenAM.  Once OpenAM issues the token (this would need to be at least cryptographically signed and ideally encrypted if it contained sensitive PII required for authorization), verification and decoding of the token can be done by a 3rd party application.  This is pretty straight forward to do as OpenAM leverages open standards such as JSON Web Tokens (JWT) with standard signing and encryption algorithms.

I created a quick sample node.js application that does just that.  It does the following simply using a few lines of JavaScript and can be run from a command line for testing.

  1. Authenticates to the pre-configured stateless realm in OpenAM over REST
  2. Receives the JSON response with the tokenId value and strips out the JWT component
  3. Verifies the tail signature using HS256 and a shared secret configured by OpenAM to prove the token hasn't been tampered with
  4. Decodes the token from base64 and introspects the JSON contents
The code is available here.

The introspection aspect in step 4, could be easily expanded to perform additional queries of the contents, such as looking for certain claims or profile attributes that could be used by an application, in order to perform an authorization decision.

See the following draft documentation for further details on configuration of stateless tokens and the implications of the approach over stateful -


Popular posts from this blog

WebAuthn Authentication in AM 6.5

ForgeRock AccessManagement 6.5 , will have out of the box integration for the W3C WebAuthn . This modern “FIDO2” standard allows cryptographic passwordless authentication – integrating with a range of native authenticators, from USB keys to fingerprint and facial recognition systems found natively in many mobile and desktop operating systems. Why is this so cool? Well firstly we know passwords are insecure and deliver a poor user experience. But aren’t there loads of strong MFA solutions out there already? Well, there are, but many are proprietary, require complex integrations and SDK’s and ultimately, don’t provide the level of agility that many CISO’s and application designers now require.  Rolling out a secure authentication system today, will probably only result in further integration costs and headaches tomorrow, when the next “cool” login method emerges. Having a standards based approach, allows for easier inter-operability and a more agile platform for chan

Implementing Zero Trust & CARTA within AM 6.x

There is an increasing focus on perimeterless approaches to security design and the buzzy "defensive security architectures".  This blog will take a brief look at implementing a contextual and continuous approach to access management, that can help to fulfil those design aspirations. The main concept, is to basically collect some sort of contextual data at login time, and again at resource access time - and basically look for differences between the two.  But why is this remotely interesting?  Firstly, big walls, don't necessarily mean safer houses.  The classic firewall approach to security.  Keeping the bad out and the good in.  That concept no longer works for the large modern enterprise.  The good and bad are everywhere and access control decisions should really be based on data above and beyond that directly related to the user identity, with enforcement as close as possible to the protected resource as possible. With Intelligent AuthX, we can start to collect an

Set Session Limits Using Context

Session limits typically cover 4 main items: total number of sessions a user can have at any one time, the max length of each session, the max idle time and max caching time. In an out of the box deployment in ForgeRock AM, these settings are configured via the session service.  However there are few tweaks than can be made to allow these settings to be run via a per user or per tree flow.  For example. think of the following scenario - user is logging via a device, location or network that has a higher risk rating.   Perhaps you would like to reduce session length on a BYOD device running an out of support version of Android to have a length of only 15 minutes.  If they switched back to their main trusted device, we can spin that back to 1hr. Another example, could be the spotting of a higher suspicion of bot activity for a particular user.  Maybe we need to set the entire quota limit to 1, to stop a bot spawning multiple sessions with the same credentials. This is all pretty trivial