A First Login With No Consent Screen
On June 18, 2026, the MCP Blog announced the Enterprise-Managed Authorization (EMA) extension as stable. When an organization defines its policy once in an IdP such as Okta, users receive the org's connected bundle of MCP servers at first login and never pass through a per-server OAuth consent screen. Whether it is the first Asana connection or the tenth Figma one, there is no click-through approval — the popup-approval friction that used to repeat all through onboarding is gone.
How ID-JAG and Okta XAA Exchange Tokens
The authorization step that consent screens used to perform now lives inside the SSO flow. When a user logs in via SSO, the client receives an Identity Assertion JWT Authorization Grant (ID-JAG) and exchanges that assertion for each MCP server's access token. Okta's XAA (Cross App Access) protocol, which governs this exchange, is built into the MCP authorization spec, so a single IdP-issued assertion takes the place of the separate consent each server used to demand.
Initial Support, and the Trade You Make For It
Initial support starts with Okta on the IdP side, the Anthropic Claude product family and VS Code on the client side, and Asana, Atlassian, Canva, Figma, Linear, and Supabase among the servers. For enterprise delivery teams, the price of removing onboarding friction is explicit. Every decision to grant or cut access now funnels into IdP policy alone, which makes IdP group and role design the single point of failure for access control.
Operating in the IdP Single-Point Era: From Policy to Revocation Drills
(a) Planning and target numbers: decide what you measure before turning EMA on. Manage server-by-group policy coverage as a matrix, with zero undefined cells against approved combinations as your baseline. Define access-revocation lead time as the interval from a departure or role-change ticket to the agent's access being cut, and target under 24 hours — under 1 hour for sensitive servers. Track unapproved server-connection attempts as a weekly trend, using it as an early warning that a new server's policy is missing.
Without a coverage matrix, the "just connect everything" temptation grows. Draw the cross-table of six servers against dozens of groups first, and every cell to fill for a new server becomes visible while policy gaps surface on the dashboard.
(b) Three failure patterns: first, connecting servers in bulk while IdP groups and roles are still untidy. If Supabase rides along into the marketing group, no consent screen means no one notices. Second, missing agent-access revocation on departure or transfer — the account is deactivated, but issued access tokens stay alive until expiry, and the lead-time metric collapses. Third, losing the minimal-disclosure function that per-server consent screens provided, so users no longer know which tools were opened at which scope.
(b') Recovery branches: undo a wrong combination by editing the group assignment in IdP policy, not by switching the server off. Revocation must pair removing the group or role in the IdP with token invalidation on the server side; the longer the token lifetime, the more explicitly you need an active revocation path. Compensate for the lost disclosure with a separate notice that summarizes, at first connection, which servers were attached at which scope.
(c) Operations checklist: register servers in the order of group-assignment review, scope confirmation, connect a pilot group first, then roll out broadly, and record an approved cell in the coverage matrix as each server joins. Logs must carry user, group, server, issued ID-JAG identifier, token-exchange timestamp, and revocation events as required fields so you can reconstruct access history and answer audits. Split unapproved connection attempts into their own alert to catch missing new-server policy immediately.
(d) Revocation drills and the improvement loop: each quarter, run a revocation drill with a mock departure or role move, measure the real lead time, and if it crosses the target, adjust IdP group structure and token-lifetime settings. Servers topping the unapproved-attempt list point to gaps in the policy matrix, so fold them into coverage at the weekly review. A revocation procedure that exists only on paper, with no drill, breaks against the lead-time metric on the first real departure day.
An Access-Control Checklist You Can Use Now
EMA removes the consent-screen friction but concentrates control responsibility in one place: IdP policy. Declare zero undefined cells in the server-by-group coverage matrix and a revocation lead time under 24 hours as if they were code, tidy groups and roles before registering servers, and run quarterly revocation drills plus continuous monitoring of unapproved connection attempts — then the same operating skeleton holds even when a non-Okta IdP or a new server joins.
References
Enterprise-Managed Authorization: Zero-touch OAuth for MCP — MCP Blog