Tools MCP and External Integration
MCP Authentication — Stack
Mcp authentication › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
Most of this is standard authorisation infrastructure applied to a connection shape it was not designed around, so the criteria are about fit rather than features.
- Metadata discovery. Whether the components involved can discover each other's endpoints and requirements from published metadata, instead of requiring every pairing to be configured by hand.
- Audience binding. Whether issued credentials can be constrained to a single target, and whether the receiving side actually verifies that constraint rather than accepting any validly signed token.
- Dynamic client onboarding. Whether an application can register itself without an administrator, and whether that registration can be constrained — by invitation, software statement, or policy — once it is enabled.
- Scope granularity. How fine the consentable units can be, and whether the identity provider's model can express per-offering rather than per-service grants.
- Proof of possession. Whether credentials can be bound to a key or a client certificate, so a stolen bearer token is not independently usable.
- Interactive flow ergonomics. Whether the authorisation exchange can be completed from the host's own interface, including on devices without a usable browser redirect.
- Lifetime and renewal. Whether short credential lifetimes with silent renewal are practical, since a conversational session routinely outlives a sensible token lifetime.
- Local-server story. Whether the approach has anything to say about a server running as a child process on the user's machine, where no network authentication exists.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Existing enterprise identity provider as the authorisation server | Organisations with workforce identity already in place; reuses lifecycle, conditional access, and revocation | Scope models are service-shaped; expressing per-offering consent usually means inventing a scope naming convention |
| Dedicated open-source authorisation servers (Keycloak, Ory Hydra, Authentik and similar) | Deployments needing full control over grants, clients, and token shape | You now operate an authorisation server, with the key rotation and availability obligations that implies |
| Managed consumer and developer identity platforms | Products whose users are not in a corporate directory | Per-monthly-user pricing and vendor-specific extensions are the two things that make migration hard later |
| Delegating to the backing system's own authorisation (acting as a client of the upstream API) | Servers that front a single third-party service that already has a consent flow | The user consents to the upstream, not to your server; your audit trail and theirs will not agree |
| Mutual TLS between services | Server-to-server connections inside one trust domain, where no human is present | Certificate distribution and rotation; it identifies a workload, and says nothing about which user a call is for |
| Workload identity frameworks (SPIFFE and compatible runtimes) | Fleets where the caller is a service and the platform can attest it | Solves workload authentication only; end-user delegation still needs a token layer on top |
| Shared static API keys in configuration | Prototypes and single-operator deployments | No attribution, no per-user revocation, and a rotation event that touches every consumer at once |
| Process trust for locally spawned servers | Developer tooling on a single user's machine | The only controls available are package provenance, signing, and operating-system confinement; there is no protocol-level answer |