Notifications
Clear all
Topic starter
07/06/2026 9:16 pm
TL;DR: MCP security depends on OAuth 2.1, PKCE, metadata discovery, dynamic registration, and strict JWT validation so AI clients can be identified, scoped, and revoked before they trigger real-world actions, according to WorkOS. The key shift is that authentication and authorization become runtime control points, not setup tasks.
NHIMG editorial — based on content published by WorkOS: The developer’s guide to MCP auth
Questions worth separating out
Q: How should security teams authenticate MCP clients in production?
A: Use OAuth 2.1 for production MCP access, with short-lived scoped tokens and server-side revocation.
Q: Why do static API keys create so much risk in MCP environments?
A: Static API keys create risk because they behave like permanent bearer credentials.
Q: What breaks when JWT validation is too loose on an MCP server?
A: Loose JWT validation lets the server accept tokens it should reject, which can turn a limited client into an over-privileged one.
Practitioner guidance
- Replace static keys with scoped OAuth flows Use OAuth 2.1 for production MCP access and reserve API keys for temporary local setups only.
- Enforce PKCE for every public client Reject any MCP client registration or token exchange that does not use PKCE when the client cannot protect a secret.
- Validate JWT claims before tool execution Check signature, issuer, audience, expiry, and scope on the server side before any request reaches a tool or downstream API.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step OAuth 2.1 and PKCE flow diagrams for MCP clients and servers
- Concrete examples of protected resource metadata and authorization server metadata payloads
- Dynamic client registration request and response patterns for MCP ecosystems
- WorkOS RBAC mapping examples that translate OAuth scopes into internal permissions
👉 Read WorkOS's guide to securing MCP authentication with OAuth 2.1 →
MCP auth and PKCE: what IAM teams need to validate?
Explore further
08/06/2026 9:09 am
MCP auth is really an NHI governance problem disguised as a protocol guide. The article describes authentication, metadata, token validation, and RBAC, but the underlying issue is who or what is allowed to act inside a delegated machine identity chain. Once an AI client can initiate state-changing actions, the server-side controls become identity controls rather than application plumbing. Practitioners should treat MCP as part of workload and agent access governance, not just API hardening.
A few things that frame the scale:
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
A question worth separating out:
Q: How do you know whether MCP authorization is actually enforcing least privilege?
A: You know it is working when a token issued for one task cannot access unrelated tools, and when denied requests are blocked before any downstream action occurs. Test the server with intentionally overbroad scopes, expired tokens, and mismatched issuers. If those requests still execute, least privilege is not being enforced.
👉 Read our full editorial: MCP auth turns least privilege into a runtime design problem
