You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# Microsoft.Identity.Web – Continuous Access Evaluation (CAE) for ManagedIdentity
2
2
3
-
## Why ClientCapabilities (cp1)?
3
+
## Why Continuous Access Evaluation?
4
4
5
-
Adding the `cp1` client‑capability tells Microsoft Entra ID your service can handle Continuous Access Evaluation (CAE) claims challenges. Tokens will include an extra xms_cc claim, allowing near‑realtime revocation.
5
+
Continuous Access Evaluation (CAE) lets Microsoft Entra ID revoke tokens or demand extra claims almost immediately when risk changes (user disabled, password reset, network change, policy update, etc.).
6
6
7
-
## Overview
7
+
A workload opts-in by sending the client-capability **`cp1`** when acquiring tokens. Entra then includes an **`xms_cc`** claim in the token so downstream Microsoft services know the caller can handle claims challenges.
8
8
9
-
cp1 signals to Microsoft Entra ID that a workload identity can handle Continuous Access Evaluation (CAE) claims challenges. When a token includes the extra xms_cc claim, Azure can revoke the token (or demand additional claims) in near‑realtime.
9
+
## What this spec adds to **Microsoft.Identity.Web**
10
10
11
-
This spec adds declarative cp1 and claims challenge auto‑handling to Managed Identity flows in Microsoft.Identity.Web (Id.Web). The goal is zero‑touch for most developers: a single configuration knob at startup, automatic 401/claims recovery at runtime.
11
+
***Declarative opt-in** – one configuration knob (`ClientCapabilities: [ "cp1" ]`).
12
+
***Transparent 401 recovery** – when a downstream Microsoft API responds with a 401+claims challenge, Id.Web automatically:
13
+
1. extracts the claims body;
14
+
2. bypasses its token cache;
15
+
3. requests a fresh token that satisfies the claims;
16
+
4. retries the HTTP call **once**.
12
17
13
-
## Typical Flow (MI + Downstream API)
18
+
The goal is **zero-touch** for most developers.
14
19
15
-
- MI token request – Id.Web sends xms_cc=cp1 at app creation.
16
-
- Access granted – Downstream API returns 200.
17
-
- Policy change – Token later revoked; next call to Downstream API gets 401 + claims.
0 commit comments