Hey folks,
I would like to start by saying how amazed I am by the great work security and identity teams worldwide are doing to enable new work paradigms while enhancing security. Folks who were considering Zero Trust models are now jumping in with both feet! It’s really an honor to be a part of your journey. Today I'm writing about an important new capability which should help minimize the time that an at-risk session stays active.
Microsoft services, such as Azure Active Directory and Office 365, use open standards and protocols to maximize interoperability (and as I’ve said before, standards are great for security too). Critical to this discussion are OpenID Connect (OIDC) for authentication and OAuth 2.0 for authorization. When a client application like Outlook connects to a service like Exchange Online, the API requests are authorized using OAuth 2.0 Access Tokens. By default, those Access Tokens are valid for one hour. When they expire, the client is redirected back to Azure AD to refresh them. That also provides an opportunity to re-evaluate policies for user access – we might choose not to refresh the token because of a Conditional Access policy, or because the user has been disabled in the directory.
Token expiry and refresh is a tried and true mechanism in the industry. That said, customers have expressed concerns about the lag between when risk conditions change for the user (e.g. moving from the corporate office to the local coffee shop, or user credentials discovered on the black market) and when policies can be enforced related to that change. We have experimented with the “blunt object” approach of reduced token lifetimes but found they can degrade user experiences and reliability without eliminating risks.
Timely response to policy violations or security issues really requires a “conversation” between the token issuer (e.g. Azure AD) and the relying party (e.g. Exchange Online). This two-way conversation gives us two important capabilities. The relying party can notice when things have changed (e.g. client coming from a new location) and tell the token issuer. It also gives the token issuer a way to tell the relying party to stop respecting tokens for a given user due to account compromise, disablement, or other concerns. The mechanism for this conversation is Continuous Access Evaluation (CAE).
Microsoft has been an early participant in the Continuous Access Evaluation Protocol (CAEP) initiative as part of the Shared Signals and Events working group at the OpenID Foundation. Identity providers and relying parties will be able to leverage the security events and signals defined by the working group to reauthorize or terminate access. It is exciting work and will improve security across many platforms and applications.
Because the security benefits are so great, we're rolling out a Microsoft-specific initial implementation in parallel to our continued work within the standards bodies. As we've worked to deploy these CAE capabilities across Microsoft services, we've learned a lot and are sharing this information with the standards community. We hope our experience in deployment can help inform an even better industry standard and are committed to implementing that standard once ratified, allowing all participating services to benefit.
Here’s what we’re doing at Microsoft with CAE right now:
We're implementing our initial approach to CAE in Exchange and Teams. The latest versions of the Outlook and Teams application on Windows, iOS, MacOS, and Android are capable of CAE and there's no action required from you if using these clients. We will expand the list of compatible clients in the coming months.
The following events will be enforced in this initial CAE rollout:
- User Account is deleted or disabled
- Password for a user is changed or reset
- MFA is enabled for the user
- Admin explicitly revokes all Refresh Tokens for a user
- Elevated user risk detected by Azure AD Identity Protection
In the future we will add more events into the instantly evaluated set, including but not limited to location and device state changes. While our goal is for enforcement to be instant, in some cases latency of up to 15 minutes may be observed due to event propagation time.
How does CAE work in Microsoft services?
CAE is implemented as follows:
Azure AD’s conversations with relying parties: Relying parties, like Exchange Online and Teams, subscribe to critical events from Azure AD. Upon receiving an event from Azure AD, the relying party knows that it should respond to future requests from the impacted client by telling the client to get a new token from Azure AD. Doing this requires that the client recognize the new response type and handle it appropriately. This is why only client applications that have implemented the flow can benefit from the behavior.
Relying parties’ conversations with Azure AD: Additionally, relying parties can synchronize key policy elements and notify Azure AD if the client varies from the terms of that policy. For example, if the policy is specific about the network the client must be on and the IP address of the client changes, the relying party can determine whether to redirect the client to Azure AD for token re-issuance.
We will initially enable CAE only for tenants with no Conditional Access policies. Because risk and policy are evaluated in real time, clients that negotiate CAE-aware sessions will rely on CAE instead of existing static Access Token Lifetime policies. Our first incremental step to this approach is to increase Access Token lifetime to 24 hours in CAE enabled sessions. Revocation is driven by risk and policy evaluation, not an arbitrary timeframe. This will increase the stability of your applications without affecting your security posture. We will use our learning from this phase of CAE to inform our ongoing rollout to additional Microsoft services.
I'm incredibly excited about this new capability – real time policy response is something we’ve discussed and worked towards in the industry for years, and this is an important step towards enhancing the security of your organizations and users.
As always, I ’d love to chat with you about the feature at @alex_t_weinert
Stay safe out there!