Part of MCP Builders — The Producer Playbook. Chapter 3 of 6.
Chapter 2 ended with a promise: design as if tokens outlive the employee who created them. Enterprise-managed auth is how you keep that promise at scale.
Individual OAuth works fine for one developer clicking Allow. It falls apart at 500 employees. The admin enables your connector org-wide, and then every single user hits an authorization screen, every new hire joins an OAuth queue, and every departure leaves a refresh token quietly alive in your database.
The fix landed as an open extension to the MCP authorization spec — the same one behind Anthropic and Okta's enterprise-managed connectors. That post covered it from the buyer's side. This chapter is the provider's side: what your server has to implement so an IT admin can provision it once and let their identity provider do the rest.
The shift in one sentence
Individual OAuth: each user authorizes your server, and you store their tokens.
Enterprise-managed auth: an admin authorizes your server once, the organization's identity provider vouches for each user at call time, and access follows the groups you already trust.
You stop being the system of record for who is allowed in. The IdP is. Your job shrinks to honoring the identity the client presents and mapping it to the right tools.
Who is in the room now
Chapter 2 had a four-hop delegation chain. Enterprise-managed auth adds an admin and an IdP, and moves the trust anchor:
- IT admin — connects your server as an organizational connector, once
- Identity provider — Okta at launch; Entra ID, Google Workspace, others following
- MCP client — Claude Team/Enterprise, and other clients as they adopt the extension
- Your MCP server — validates the identity, maps groups to tools, calls upstream
- Upstream API — still enforces its own scopes
The user is still there — but they no longer click Allow. They log in to their client, and your connector is simply present, scoped to whatever their IdP group entitles them to.
What the extension actually asks of your server
You do not need to reimplement OAuth from scratch. You need to make your server a well-behaved resource server in an IdP-brokered flow. Concretely:
| Responsibility | What it means in practice |
|---|---|
| Publish authorization metadata | Expose a protected-resource metadata document so clients discover your auth server, scopes, and token requirements |
| Accept IdP-issued tokens | Validate access tokens minted through the org's identity provider — signature, issuer, audience, expiry |
| Support dynamic client registration | Let clients register without a human pasting a client secret into a form |
| Map identity to entitlements | Turn a verified user + group claims into a concrete tool and scope set |
| Honor revocation | When the IdP deprovisions a user, their next tool call fails — no local grace period |
The MCP SDKs handle transport and JSON-RPC. The spec covers token formats. This chapter is about the judgment layer on top: which group gets which tools, and how you prove to a security team that the mapping is safe.
The provisioning flow, provider side
Here is what happens when an admin adds your server, and where your code runs:
- Admin connects your server in their client's admin console and points it at your metadata URL
- Client discovers your auth requirements from the protected-resource metadata — no manual scope entry
- Client registers dynamically and establishes trust with the org's IdP
- User logs in to the client; the IdP issues a token carrying identity and group claims
- Client calls your tool with that token in the request
- Your server validates the token and reads the claims
- Your server maps claims to a tool bundle and either serves the call or refuses it
Steps 6 and 7 are yours to own. Everything before that is protocol and client plumbing.
Map IdP groups to tool bundles — not to raw scopes
The single most useful design decision: express entitlements as named tool bundles, then let admins attach IdP groups to bundles. Admins think in groups (eng-all, support-tier2, finance-admins). They do not think in your internal scope strings.
| IdP group | Tool bundle | Tools exposed |
|---|---|---|
support-readonly | Read | get_customer, search_tickets |
support-tier2 | Read + narrow write | above + create_comment, create_draft |
billing-admins | Sensitive write | above + create_refund (audited) |
Default deny. A verified user in no mapped group gets an empty tool list — not your full read surface. Enterprises expect allow-lists, not opt-outs.
This is the same read/write/admin split from Chapter 2, promoted from a code convention to a provisioning contract the admin can see and audit.
Trust the IdP, verify every token
Accepting an IdP-brokered token is not the same as trusting any bearer string. On every tool call:
- Verify the signature against the IdP's published keys — cache them, rotate on schedule
- Check the issuer matches the org's configured IdP, not any issuer
- Check the audience is your server — reject tokens minted for something else
- Enforce expiry — short-lived access tokens are the point; do not extend them locally
- Read group claims fresh — do not cache a user's entitlements past token lifetime
The upside of getting this right: you hold far fewer long-lived secrets. In pure enterprise-managed mode, you may store no user refresh tokens at all — the IdP is the vault. That is a smaller attack surface and a much shorter security questionnaire.
Offboarding becomes someone else's job — if you let it
The ghost-employee problem from Chapter 2 dissolves here, but only if you resist the temptation to cache entitlements.
- User leaves → IdP deactivates the account
- Next token request fails at the IdP → no valid token reaches you
- Any cached entitlement you kept → the one hole that reintroduces the ghost
Rule: entitlements live and die with the token. If you must cache group lookups for performance, cap the TTL at the token lifetime and never longer.
Audit logging: the artifact security actually buys
Enterprise-managed auth turns your logs into a compliance deliverable. For each tool call, record — without secrets:
- Who — stable user identifier from the token (not the raw token)
- What — tool name and non-sensitive parameters
- Which entitlement — the bundle that authorized it
- Result — success, refusal, upstream error
- When — timestamp and, ideally, upstream latency
Redact token values and payload secrets in every trace. "We can show you exactly which user ran which tool under which group" is the sentence that closes enterprise deals.
Document both paths — you are not deprecating individual OAuth
Solo developers and small teams still want the paste-a-key or click-Allow path from Chapters 1 and 2. Enterprise-managed auth is additional, not a replacement. Your server page and directory listing should describe both clearly:
| Audience | Path | Setup |
|---|---|---|
| Solo dev | API key / individual OAuth | Local config, staging key |
| Small team | Individual OAuth | Per-user Allow, scoped client |
| Enterprise | IdP-managed provisioning | Admin connects once, groups map to bundles |
Buyers comparing connectors in a server audit now check for the enterprise row specifically. A missing row reads as "not ready for us."
Migrating a server that already shipped individual OAuth
You do not rip anything out. You add a lane.
- Publish protected-resource metadata alongside your existing OAuth endpoints
- Add IdP token validation as a second accepted auth mode on your tool handlers
- Externalize your scope map into named bundles the admin can bind to groups
- Default new org installs to enterprise-managed; keep individual OAuth for existing solo users
- Version the change — do not silently broaden what existing tokens can reach (the Chapter 2 silent-scope-expansion trap)
Provider-side mistakes we already see
Caching entitlements "for speed"
You reintroduce the ghost employee. Bind entitlement lifetime to token lifetime, full stop.
Trusting group names from the wrong issuer
A token with billing-admins in the claims means nothing unless it came from this org's configured IdP. Always check the issuer.
One giant bundle called "enterprise"
Enterprises want more granularity than solo users, not less. If every provisioned user gets every tool, you have rebuilt over-permission with an IdP logo on it.
Logging tokens or payloads
Your audit log is a security asset until it leaks a token. Redact by default.
Making enterprise auth a paid tier gate with no docs
If security cannot find how your auth works without a sales call, they assume the worst. Document the model publicly.
Builder checklist — copy into your runbook
- ☐ Protected-resource metadata published and discoverable
- ☐ IdP token validation: signature, issuer, audience, expiry
- ☐ Dynamic client registration supported
- ☐ Entitlements expressed as named tool bundles
- ☐ Default-deny for users in no mapped group
- ☐ No entitlement caching beyond token lifetime
- ☐ Audit log: who / what / entitlement / result / when — secrets redacted
- ☐ Individual OAuth path still documented for solo and small teams
- ☐ Enterprise setup notes on your README and directory listing
What's next in MCP Builders
- Hub — full chapter list
- Chapter 1: API → MCP in one afternoon
- Chapter 2: OAuth and the over-permission trap
- Chapter 4 (coming): stdio vs HTTP, hosting, and secrets — where the process runs once real orgs depend on it
Quick answers
Do I have to implement this before selling to any company?
No — small teams accept individual OAuth. But once a prospect has an IdP and a security team, enterprise-managed auth moves from nice-to-have to RFP requirement.
Is this Okta-only?
Okta is first. The extension is an open MCP standard, so build to the spec, not to one IdP. Entra ID, Google Workspace, and others are on the same trajectory.
Can I still store refresh tokens?
In pure enterprise-managed mode you often store none — the IdP brokers identity per call. If you keep any, encrypt them and bind their life to the IdP's revocation.
What if the client my customer uses hasn't adopted the extension yet?
Fall back to individual OAuth for that client, and expose enterprise-managed auth where it is supported. Document which clients get which path.
When do I submit to Influzer.ai?
As soon as your enterprise setup notes are honest and public. Governed connectors get compared side by side — being listed with a clear auth model is how buyers shortlist you.
Final thought
Chapter 2 was about not handing an agent too much. Chapter 3 is about handing the decision of who gets in back to the systems enterprises already trust.
When you stop being the identity store and start being a clean resource server that honors the IdP, two things happen: your attack surface shrinks, and your sales cycle does too. Security teams say yes faster to connectors that speak their language.
Externalize the scope map. Trust the IdP, verify every token. Log everything, leak nothing. Then get listed with your enterprise story front and center — and read the full chapter list for what comes after hosting.
Be the first to share your thoughts.