Skip to content

feat: Add Enterprise Managed Authorization (SEP-990) support #1305

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
aniket-okta wants to merge 4 commits into
base: main
Choose a base branch
from
Open

feat: Add Enterprise Managed Authorization (SEP-990) support #1305

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
971dd8b
feat: Add Enterprise Managed Authorization (SEP-990) support
aniket-okta Feb 18, 2026
4d8699a
test: add OAuthTestBase integration tests
aniket-okta Apr 6, 2026
6390f2a
refactor: split public types into separate files, remove SEP-990 refs…
aniket-okta Apr 12, 2026
db67570
refactor: rename to CrossApplicationAccess*, shrink public surface, f…
aniket-okta May 20, 2026
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
32 changes: 32 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,6 +31,38 @@ For more information about MCP:
- [Protocol Specification](https://modelcontextprotocol.io/specification/)
- [GitHub Organization](https://github.com/modelcontextprotocol)

## Enterprise Auth / Enterprise Managed Authorization
Copy link
Copy Markdown
Contributor

@halter73 halter73 May 21, 2026 •
edited
Loading

Choose a reason for hiding this comment

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

Suggested change
## Enterprise Auth / Enterprise Managed Authorization
## Cross-Application Access (Identity Assertion Authorization Grant flow)

I think we should de-emphasize "Enterprise" now that it's no longer part of the type names. This appears to align better with the TS SDK's conceptual docs.

https://github.com/modelcontextprotocol/typescript-sdk/blob/48251fe2cb24fb9b2a12ef3cffb5f5bd196a7ea4/docs/client.md#L169


The SDK provides Cross-Application Access support for the [Identity Assertion Authorization Grant flow](https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/draft/enterprise-managed-authorization.mdx),
enabling enterprise SSO scenarios where users authenticate once via their enterprise Identity Provider and
access MCP servers without per-server authorization prompts.

The flow consists of two token operations:
1. **RFC 8693 Token Exchange** at the IdP: ID Token → JWT Authorization Grant (JAG)
2. **RFC 7523 JWT Bearer Grant** at the MCP Server: JAG → Access Token

### Using CrossApplicationAccessProvider

```csharp
using ModelContextProtocol.Authentication;

var provider = new CrossApplicationAccessProvider(new CrossApplicationAccessProviderOptions
{
ClientId = "mcp-client-id",
IdpTokenEndpoint = "https://company.okta.com/oauth2/token",
IdpClientId = "idp-client-id",
IdTokenCallback = async (context, ct) =>
{
// Return the OIDC ID token from your SSO session
return myIdToken;
Copy link
Copy Markdown
Contributor

@halter73 halter73 May 21, 2026

Choose a reason for hiding this comment

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

This callback is async but has no await, which will compile-warn (CS1998). Either drop async and return Task.FromResult(myIdToken), or make the example realistically asynchronous by showing the ID-token fetch:

Suggested change
return myIdToken;
// Fetch a fresh ID token from your SSO session.
return await mySsoClient.GetIdTokenAsync(cancellationToken);

}
});

var tokens = await provider.GetAccessTokenAsync(
resourceUrl: new Uri("https://mcp-server.example.com"),
authorizationServerUrl: new Uri("https://auth.mcp-server.example.com"));
Copy link
Copy Markdown
Contributor

@halter73 halter73 Feb 18, 2026 •
edited
Loading

Choose a reason for hiding this comment

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

We experimented with adding some of these OAuth flows in #1178, but we haven't added it yet since it's an Auth Extension rather than a primary part of the spec. See https://github.com/modelcontextprotocol/ext-auth/blob/5c50488e96e242b4d09c2b97ae47fa152d96a836/specification/draft/enterprise-managed-authorization.mdx and https://github.com/modelcontextprotocol/conformance/blob/066b2d70800a8bd6bca82e000007c9877b443e5b/src/scenarios/client/auth/index.ts#L50-L55.

I do like that this doesn't pollute the ClientOAuthOptions like #1178 did, but I wonder if this wouldn't be better as a separate package. It looks like you could use these APIs to get the access token for any HttpClient needing to support these OAuth flows. It seems like something with more features like Duende.AccessTokenManagement.OpenIdConnect might be a better general solution for this than something tied specifically to the MCP C# SDK.

Copy link
Copy Markdown
Author

@aniket-okta aniket-okta Feb 19, 2026 •
edited
Loading

Choose a reason for hiding this comment

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

Thanks for the review @halter73 ! Good points - I want to address the packaging question.

Why I placed this in ModelContextProtocol.Core:

  • This was requested in Implement SEP-990: Enterprise Managed Authorization (Extension) #949, filed by the MCP spec team and tracked on the project board. Both the Go SDK (go-sdk#770) and TS SDK (typescript-sdk#1531) include this in their main packages - not as separate packages.
  • While the underlying RFCs (8693, 7523) are generic, the implementation is MCP-specific - it uses the urn:ietf:params:oauth:token-type:id-jag token type, MCP resource URIs, and the EnterpriseAuthProvider is built around the MCP orchestrator context (ResourceUrl, AuthorizationServerUrl).
  • Re: Duende - it handles OIDC token lifecycle for ASP.NET Core apps, but doesn't implement the ID-JAG token exchange or the MCP-specific JWT bearer grant pattern. Users would still need to orchestrate the full flow manually.
  • There are conformance tests (CrossAppAccessCompleteFlowScenario) for this flow already.

That said, I'm happy to move this to a separate package (e.g. ModelContextProtocol.Auth.Enterprise) if the team prefers that pattern for auth extensions. The code is self-contained with no dependencies on SDK internals, so it would be a straightforward move. What do you think?

Copy link
Copy Markdown
Contributor

@halter73 halter73 Feb 19, 2026

Choose a reason for hiding this comment

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

Makes sense. Are APIs that just provide the access token that we can then use to create a new client sufficient? I know for the normal OAuth flows we need a bit deeper integration to support scope step up and token refresh. I suppose scope step up would be hard without an interactive user and a browser, but refresh seems like it could still be useful. I suppose you could always refresh manually and call ResumeSessionAsync with the new access token. What do the other SDKs do for token refresh in this case?

Copy link
Copy Markdown
Contributor

@halter73 halter73 Feb 19, 2026

Choose a reason for hiding this comment

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

As for the separate package, I don't think that's necessary. My primary concern would be not making ClientOAuthOptions overly confusing, but this PR avoids that by providing completely independent APIs.

Copy link
Copy Markdown
Author

@aniket-okta aniket-okta Feb 23, 2026

Choose a reason for hiding this comment

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

Thanks for the great questions, @halter73!

On scope step-up:

Correct - scope step-up is fundamentally incompatible with non-interactive enterprise flows. The whole point of SEP-990 is that the user has already authenticated once via their enterprise IdP (SSO), so there is no browser/user available at MCP-request time. Scope step-up would require re-prompting the user, which this flow is designed to eliminate. So no step-up support is by design, and that matches the behavior in both the Go and TS SDKs.

On token refresh:

Neither the Go SDK (go-sdk#770) nor the TS SDK (typescript-sdk#1531) implement explicit refresh token handling for this flow. The reason is structural: the ID-JAG itself is short-lived by design (it's a one-time assertion, not a long-lived credential). When the access token expires, the correct action is to re-run the full flow — re-request a fresh ID-JAG from the IdP, then exchange it for a new access token. This is effectively a "refresh" but through the full two-step exchange rather than a refresh_token grant.

Copy link
Copy Markdown
Author

@aniket-okta aniket-okta Feb 23, 2026

Choose a reason for hiding this comment

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

In this PR, that is already supported via:

  1. Automatic re-execution: EnterpriseAuthProvider.GetAccessTokenAsync() checks _cachedTokens.IsExpired and re-runs the full flow when the token expires.
  2. Manual invalidation: Callers can call InvalidateCache() to force a fresh exchange on the next call.

Your suggestion of calling ResumeSessionAsync with a new access token after InvalidateCache() would work well for the HttpClient-based integration. However, a more seamless pattern might be to expose a CreateAuthorizationHeaderAsync() / GetAccessTokenAsync() method that can be wired directly into an HttpMessageHandler (similar to how the TS SDK's CrossAppAccessProvider plugs into withOAuth). This would give transparent token refresh on 401 without the caller needing to manage ResumeSessionAsync manually. I can add an HttpMessageHandler-based integration helper to EnterpriseAuthProvider if that would be the preferred approach, happy to follow whatever pattern the team is converging on for auth handlers.

Let me know if you'd like me to add refresh-on-401 integration or any deeper transport hookup in this PR, or if the current GetAccessTokenAsync + manual ResumeSessionAsync pattern is sufficient for the initial merge.

```

Copy link
Copy Markdown
Contributor

@halter73 halter73 May 22, 2026 •
edited
Loading

Choose a reason for hiding this comment

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

I thought this was in a conceptual doc. This doubles the size of our README. We try to keep this pretty slim. I would move this to somewhere under the docs/ directory. We don't have client OAuth documented yet, and I'm not going to ask you to do that. Feel free to add it as a section to transports.md, and we'll move it to a dedicated client OAuth doc once we create that.

If you want to go the extra mile, you could add this flow to ProtectedMcpServer and ProtectedMcpClient. These both run against the TestOAuthServer that you've already updated, so I think you're already most of the way there. It could be helpful for referencing from the /docs too. We already do that in identity.md for the server side at least.

## License

This project is licensed under the [Apache License 2.0](LICENSE).
Loading