Problem or motivation
MCP's Enterprise-Managed Authorization (EMA) extension (io.modelcontextprotocol/enterprise-managed-authorization) is now stable. It makes the org's IdP the authoritative decision-maker for MCP access: employees log in once via corporate SSO and get zero-touch access to approved servers — no per-server consent screen — while security teams provision/revoke and audit centrally. Anthropic (Claude, Claude Code, Cowork), VS Code, Okta, and servers like Atlassian, Linear, Figma, Canva and Supabase already support it.
mcp.apify.com authenticates only via long-lived APIFY_TOKEN; #741 tracks adding standard interactive OAuth/SSO. EMA is the enterprise step beyond that: without it, orgs can't grant or revoke Apify MCP access from their IdP, which blocks adoption for security-governed teams.
Proposed solution
Implement the MCP-server / authorization-server side of the EMA flow on mcp.apify.com:
- Declare
io.modelcontextprotocol/enterprise-managed-authorization in the server's protected-resource / authorization metadata.
- Accept the RFC7523
urn:ietf:params:oauth:grant-type:jwt-bearer grant at the token endpoint and validate the IdP-issued ID-JAG: typ is oauth-id-jag+jwt, signature against the IdP JWKS, aud = our AS issuer URL, resource = our RFC9728 resource id, client_id matches client auth, plus exp/iat/jti.
- Map the ID-JAG
sub (+ optional email) to an Apify identity (account linking) and the scope claims to Apify permissions.
- Issue a short-lived Apify MCP access token on success.
Builds on #741 (interactive OAuth/SSO + DCR). Spec: https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization — draft + reference: https://github.com/modelcontextprotocol/ext-auth (SEP-990).
Alternatives considered
Standard interactive OAuth alone (#741) still forces per-user, per-server consent and doesn't give central IdP policy, audit, or zero-touch onboarding.
Problem or motivation
MCP's Enterprise-Managed Authorization (EMA) extension (
io.modelcontextprotocol/enterprise-managed-authorization) is now stable. It makes the org's IdP the authoritative decision-maker for MCP access: employees log in once via corporate SSO and get zero-touch access to approved servers — no per-server consent screen — while security teams provision/revoke and audit centrally. Anthropic (Claude, Claude Code, Cowork), VS Code, Okta, and servers like Atlassian, Linear, Figma, Canva and Supabase already support it.mcp.apify.comauthenticates only via long-livedAPIFY_TOKEN; #741 tracks adding standard interactive OAuth/SSO. EMA is the enterprise step beyond that: without it, orgs can't grant or revoke Apify MCP access from their IdP, which blocks adoption for security-governed teams.Proposed solution
Implement the MCP-server / authorization-server side of the EMA flow on
mcp.apify.com:io.modelcontextprotocol/enterprise-managed-authorizationin the server's protected-resource / authorization metadata.urn:ietf:params:oauth:grant-type:jwt-bearergrant at the token endpoint and validate the IdP-issued ID-JAG:typisoauth-id-jag+jwt, signature against the IdP JWKS,aud= our AS issuer URL,resource= our RFC9728 resource id,client_idmatches client auth, plusexp/iat/jti.sub(+ optionalemail) to an Apify identity (account linking) and thescopeclaims to Apify permissions.Builds on #741 (interactive OAuth/SSO + DCR). Spec: https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization — draft + reference: https://github.com/modelcontextprotocol/ext-auth (SEP-990).
Alternatives considered
Standard interactive OAuth alone (#741) still forces per-user, per-server consent and doesn't give central IdP policy, audit, or zero-touch onboarding.