Skip to content

Refine authentication/authorization langugage #8

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
PieterKas wants to merge 1 commit into
base: dmcadams-wif-extenstion
Choose a base branch
from
+16 −17
Open

Refine authentication/authorization langugage #8

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 16 additions & 17 deletions specification/draft/workload-identity-federation.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,30 +11,29 @@ long-lived credentials. This extension builds upon the baseline authorization
requirements defined in the main Authorization specification.

Workload Identity Federation is designed for scenarios where an MCP client
operates as an autonomous workload - that is, the client authenticates and
authorizes as itself rather than through an interactive OAuth authorization
flow on behalf of an end-user. In these deployments, the MCP client effectively
functions as a workload within a workload platform (such as Kubernetes or cloud
provider environments). Like the Client Credentials extension, this pattern
addresses machine-to-machine authentication use cases.
operates as an autonomous workload without any user interaction. In these
Copy link
Contributor

@D-McAdams D-McAdams Dec 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The original text aimed to avoid pedantic arguments about whether a workload is truly "autonomous without any user interaction" when the use case is a microservice deep in a call stack that is originally triggered by user interaction. In my prior experience, this was the most common situation we heard from customers and the intention was that readers not mistakenly think this spec was inapplicable for them. Hence, language anchored on how the workload authenticates and authorizes itself, rather than getting into nuances of autonomy. The original text could definitely be tightened up, though. Any thoughts on balancing these considerations?

Copy link
Collaborator Author

@PieterKas PieterKas Dec 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is a very good point - the original text may suffice. But perhaps that needs to be made more explicit so that readers have clear guidance that this applies to any workload that may be in a call chain, including when the call chain was initiated by a user? How about something like this:

Suggested change
operates as an autonomous workload without any user interaction. In these
Workload Identity Federation enables MCP clients to authenticate and authorize using their own workload identity, without relying on interactive end-user OAuth flows. This model applies whether the workload is fully autonomous or acting within a user-initiated request path, as long as the client performs non-interactive authentication. MCP clients are typically deployed within workload platforms such as Kubernetes, virtual machines, or cloud provider environments.

deployments, the MCP client is deployed as a workload within a workload
platform, such as Kubernetes, virtual machines, or a cloud provider
environment.

This extension allows an MCP client that already possesses a JWT credential
(issued by its workload platform, SPIFFE implementation, or other trusted
identity provider) to present that credential directly to an authorization
server protecting an MCP server. The authorization server validates the JWT and
issues a temporary access token suitable for accessing the MCP server.
issued by its workload platform, SPIFFE implementation, or other trusted
identity provider, to present that credential directly to an OAuth
authorization server protecting an MCP server. The OAuth authorization
server validates the JWT and issues a temporary access token suitable for
accessing the MCP server.

This approach eliminates the need for:
- Client credentials (client secrets or private keys)
- Client secrets or private keys
- Client identifiers (client_id)
- Client registration (including Dynamic Client Registration)
- Managing separate credentials for each service the client needs to access

Instead, MCP clients leverage their existing platform-provided workload identity
and "federate" to other services through trust relationships configured in the
authorization server. This significantly simplifies workload-to-service
authentication patterns while maintaining security through proper issuer trust
and claim-based authorization.
authorization server. This significantly simplifies MCP authorization,
improves security, and reduces operational complexity by removing long-lived
secrets and client registration.

### Extension Requirements

Expand Down Expand Up @@ -64,11 +63,11 @@ This extension is based on the following established specifications:

Workload Identity Federation enables autonomous MCP clients to obtain access
tokens for MCP servers by presenting existing JWT credentials issued to them as
workloads. The flow involves three primary entities:
workloads by trusted issuers. The flow involves three primary entities:

- **MCP Client**: An autonomous client seeking access to an MCP server,
possessing a JWT credential from a trusted issuer. The MCP client functions
as a workload within its deployment environment.
as a workload within its deployment environment (e.g. Kubernetes).
- **Authorization Server**: The OAuth 2.0 authorization server protecting the
MCP server, responsible for validating workload JWTs and issuing access
tokens
Expand Down Expand Up @@ -530,7 +529,7 @@ deployments.
The following recommendations apply to all deployments:
- Configuration SHOULD NOT permit the transcription of JWT claims to access
token claims without additional validation
- Authorization servers SHOULD implement explicit allowlists or policies
- Authorization servers SHOULD implement explicit allow lists or policies
defining which workload identities can access which MCP servers
- Authorization servers SHOULD log and audit all token issuance decisions for
security monitoring
Expand Down