The Microsoft CAE learning article, which describes how they manage policy violations or security issues and is based on OpenID Continuous Access Evaluation Profile (CAEP), explains how one can extend the default 1-hour token lifetime to 24 hours (or make it configurable). Microsoft has adopted this strategy because CAEP enables them to terminate sessions based on any changes to the session at the IdP (Microsoft lists 5 conditions in that article).
Using CAEP to extend token lifetimes is clearly a model that has been proven at scale. So the question is, how do you bring that into your organization?
Why worry about token lifetimes?
Organizations often use token lifetime as a means of ensuring that any session in play is not abused when the properties associated with that session are no longer valid. The idea is that a user accessing an application will be forced to redirect to the identity provider (IdP) because the token will have expired. The IdP will then re-evaluate the conditions under which the original token was issued, and issue a new token if it is valid. In the process, a user may be requested to re-authenticate, or the user may be simply redirected back to the application from where they were redirected for token refresh in the first place.
Keeping a long token lifetime, in this scenario, means that organizations are exposed to greater risk of abuse from stale sessions, whereas keeping a short token lifetime means that the user experience suffers greatly, because the application has to reconstitute the browser state when the user comes back, and possibly, the user needs to re-authenticate themselves to the IdP.
CAEP makes it possible for tokens to be kept alive for a really long time, and effectively eliminates the risk of abuse from stale sessions.
CAEP Backgrounder
Before we go there, let’s recap what CAEP is:
As seen in the picture above
- The Shared Signals Framework (SSF) provides a robust asynchronous transport mechanism with comprehensive stream controls
- CAEP events are profiles of Security Event Tokens (SETs), which are themselves a profile of JSON Web Tokens (JWTs)
- CAEP events are about session management. They indicate when something about the session has changed at the Transmitter of the events, such as:
- Session established
- Session presented
- Session revoked
- Credential change
- Device compliance change
- Assurance level change
- Token claims change
A key property of SSF is that it provides reasonable delivery guarantees. This means that if a Transmitter has an event to be sent to a Receiver (the type of which has been negotiated with the Receiver when the stream is set up), it is assured that the Receiver will receive it.
Another important property of SSF and CAEP is that the events are non-prescriptive. They describe the change that occurred at the Transmitter, but do not require the Receiver to take any specific action. This means that the Receiver can apply their own policy to decide what to do with the received event.
Short-lived IdP Tokens
A common way to ensure security in organizations is to ensure that the tokens are refreshed periodically, so that checks done at the time of user login are re-evaluated when the token is being refreshed. The token lifetime is kept short in this scheme so that if anything changes about the user (e.g., user account suspension), their session at the application is not unaware of it.
This strategy is inefficient because the user has to be redirected to the IdP periodically, and produces a poor user experience because the browser may end up having to reconstitute the application context after the redirect back to the application. It also leaves open the issue that if some components within your organization have detected an issue with the user’s session (e.g., abnormal activity within an application), the IdP may be completely unaware of it, so doing the refresh does not help.
Using CAEP to extend token lifetime
Instead of bouncing users to the IdP frequently, an alternative strategy is to keep the token lifetime long, and communicate any session revocation (or other session related events) using CAEP.
What you need
In order to do this, you need:
- A CAEP Transmitter, which can generate events when something about the session changes at the IdP
- A CAEP Receiver, which can receive events at your application and terminate application sessions, so that users may be redirected to the IdP for re-authentication
What generates events
Anything that affects the user’s session must generate events, including:
- The user changes their password at the IdP
- The IdP administrator makes a change to the user’s account
- The IdP administrator explicitly revokes a user’s session
- The user behaves abnormally at one of your applications
- The user behavior across all your applications is collectively abnormal (e.g., lateral movement)
Adopting CAEP in your organization
So let’s look at how your organization can use CAEP to extend token lifetimes in three areas: custom applications, third-party applications, and IT infrastructure.
Custom apps
For your own applications, or the ones for which you can influence the features, you can build a CAEP Receiver using open source projects such as the caep.dev open source receiver. Alternatively, you can provide suitable API endpoints in your application that may be used by products that can consume CAEP events and terminate application sessions.
Third-party apps
Many third-party apps do not yet support CAEP. However they provide API endpoints to terminate sessions, which may be called when a CAEP event is received by a product that understands CAEP.
Infrastructure (IdP, fraud detection, etc.)
Other infrastructure components may or may not support CAEP out-of-the-box, but a product that can watch for signals or changes in the user’s account or session can integrate with such products and generate the CAEP events. Where the target applications don’t yet support CAEP, such a product can also integrate with the applications’ API endpoints to dynamically terminate user sessions.
The SGNL CAEP Hub is one such product that can integrate both with infrastructure such as the IdP or HR systems, and generate CAEP events or integrate with custom API endpoints to terminate sessions. It provides a flexible action framework to determine how to react to various changes in the user’s account or session.