They are hard because many teams have not operationalised the identity plumbing required to make MCP work with existing identity providers and runtime client registration. The challenge is not the spec alone. It is the added burden of making token issuance, consent and client trust align without building one-off authorisation logic.
Why OAuth 2.1, PKCE and DCR become hard in MCP deployments
The hard part is not understanding OAuth 2.1, PKCE or DCR in isolation. It is making those controls work cleanly across MCP servers, clients, agents and existing identity providers without inventing custom authorization paths. In practice, teams must align token issuance, client trust, consent and runtime registration while keeping the deployment interoperable and supportable.
Where the complexity comes from in real MCP deployments
MCP changes the shape of the problem because the protocol often sits between an agentic client and a tool or resource server, with multiple trust boundaries that were not designed together. The server may need to act as an OAuth resource server, the client may be dynamic rather than pre-registered, and the user or operator still expects normal identity-provider behaviour. The moment those pieces do not line up, teams start adding one-off authorisation logic that undermines the standard flow. See the MCP authorisation model in Model Context Protocol: Authorization specification.
PKCE is straightforward when a single app is already registered and the redirect path is stable. It becomes harder in MCP because the client may be distributed, ephemeral or mediated by an agent runtime, which makes redirect handling, verifier storage and callback integrity more fragile. DCR adds another layer of operational work because registration is no longer a one-time admin task, it becomes part of the runtime lifecycle. That is why OAuth 2.1 plus PKCE plus DCR is often an integration programme, not just a protocol choice.
The underlying standards are mature, but they assume disciplined client modelling and consistent token handling. OAuth 2.0 and modern best practice are designed around clear client types and tightly scoped authorization flows, while sender-constrained or audience-bound tokens reduce abuse when tokens move across components. For the core protocol model, RFC 6749: The OAuth 2.0 Authorization Framework and RFC 9700: Best Current Practice for OAuth 2.0 Security are the right anchors.
Why identity-provider alignment is the real bottleneck
Most MCP friction comes from identity plumbing, not from the spec text itself. Teams must decide whether MCP clients are confidential, public or mixed, how consent is obtained, whether registrations are pre-provisioned or dynamic, and how scopes map to actual tool access. If the identity provider cannot express those distinctions cleanly, teams are pushed toward shortcuts such as shared secrets, broad scopes or proxy-based token forwarding, all of which weaken the model.
DCR also introduces governance questions that are easy to underestimate: who is allowed to register a client, what metadata is trusted, how long registrations live, and how revocation works when an agent or integration is retired. Those questions matter because MCP deployments are often built around fast-moving software rather than long-lived human-owned applications. The result is that the desired “plug in any tool, let the IdP handle trust” experience depends on careful lifecycle design.
For the protocol-facing side of this problem, the official OWASP Agentic AI Top 10 is useful because it frames identity and privilege abuse, tool misuse and inter-component trust failures as first-class risks in agentic systems.
How the control set gets complicated at the edge
PKCE, DCR and OAuth 2.1 become especially awkward when developers try to make one flow cover every tool, every agent and every environment. Public clients need strong proof that the callback belongs to the original request, confidential clients may need stronger client authentication, and some deployments also need audience restriction or token exchange to stop credentials from roaming between services. Those are not optional refinements in MCP, they are often the difference between a usable design and a brittle one.
That is why practitioners often end up evaluating adjacent controls such as sender-constrained tokens, resource indicators and token exchange to keep tokens bound to the right party and the right target. The standards that help most here are RFC 8707: Resource Indicators for OAuth 2.0, RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) and RFC 8693: OAuth 2.0 Token Exchange. Those mechanisms are not required in every deployment, but MCP makes their absence more visible because the boundary between client, agent and tool is so easy to blur.
Risk and Threat Considerations
MCP deployments that bolt OAuth on late tend to inherit exposure from token leakage, overbroad authorization and weak client trust. The main risk is not just failed login, it is delegated access that can be replayed, forwarded or overextended across tools and environments. That is especially dangerous when agents or automation can make repeated requests at machine speed.
Failure mechanism: The deployment treats registration, consent and token handling as integration details, so teams compensate with broad scopes, token passthrough or shared credentials instead of binding access to a specific client, resource and runtime.
Impact: A compromised agent, client or intermediary can gain persistent or lateral access to tools and data beyond the original intent, and revocation becomes harder because trust was never cleanly modelled.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP auth failures often become privilege abuse across agent/tool boundaries. |
| Recommendation — Bind agent actions to least-privilege scopes and strong runtime authorization. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | OAuth 2.1 and PKCE failures in MCP can weaken API client authentication. |
| API5 — Broken Function Level Authorization | MCP tool access must map to allowed functions, not just valid tokens. | |
| Recommendation — Enforce robust client authentication and proof-of-possession controls. Authorize each tool action explicitly against intended function scope. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | DCR, PKCE and token handling depend on secure lifecycle control of authenticators. |
| IA-9 — Service Identification and Authentication | MCP clients and servers commonly authenticate as services or workloads. | |
| Recommendation — Manage token, secret and verifier lifecycles with rotation and revocation. Authenticate MCP services with workload-appropriate strong credentials. | ||
Practitioner Guidance
What to prioritise: Decide first whether the MCP client is truly public, confidential or dynamically registered, because that choice drives PKCE, client authentication and consent design. If you cannot answer that cleanly, the implementation is not ready for production.
What to verify: Confirm that token audience, redirect handling and registration ownership are explicit, and that you can revoke a client or agent without breaking unrelated users. Also verify that no component depends on token passthrough as a convenience shortcut.
Common mistake: Treating DCR as a way to avoid governance, rather than a lifecycle control that still needs policy, review and expiry. Dynamic registration removes manual friction, but it does not remove accountability.
Practitioner takeaway: The hardest part is designing a trustworthy runtime relationship between identity provider, MCP client and tool server, so the standard remains the control path instead of a custom authorization workaround.