Enterprise managed authorization by radar07 · Pull Request #770 · modelcontextprotocol/go-sdk

radar07 · 2026-01-30T13:53:08Z

auth, oauthex: implement Enterprise Managed Authorization (SEP-990)
This PR implements Enterprise Managed Authorization (SEP-990) for the Go MCP SDK, enabling MCP Clients and Servers to leverage enterprise Identity Providers for seamless authorization without requiring users to authenticate separately to each MCP Server.
Overview
Enterprise Managed Authorization follows the Identity Assertion Authorization Grant specification (draft-ietf-oauth-identity-assertion-authz-grant), implementing a three-step flow:

Single Sign-On (SSO): User authenticates to the MCP Client via enterprise IdP (Okta, Auth0, Azure AD, etc.)
Token Exchange (RFC 8693): Client exchanges ID Token for Identity Assertion JWT Authorization Grant (ID-JAG) at the IdP
JWT Bearer Grant (RFC 7523): Client exchanges ID-JAG for Access Token at the MCP Server
This enables:

For end users: Single sign-on across MCP Clients and Servers—no manual connection/authorization per server
For enterprise admins: Centralized visibility and control over which MCP Servers can be used within the organization
For MCP clients: Automatic token acquisition without user interaction for each server

Closes: #628

maciej-kisiel · 2026-01-30T15:33:36Z

Hi @radar07, thanks for submitting this PR. Could you link the issue that it is addressing?

Also, as a heads-up: it will likely take some time to review your proposal. Both because it's quite large, but more importantly I'm also working on a proposal how to structure the client-side OAuth implementation and this change will need to be aligned with it.

radar07 · 2026-01-31T15:03:22Z

Thanks @maciej-kisiel. I updated the description with the SEP that this PR solves.

radar07 · 2026-02-03T04:50:57Z

@maciej-kisiel I'd be happy to contribute to OAuth implementation. Let me know if I can help with anything. Just want to know if I should add conformance tests to this because I can see that there are PRs related to conformance tests.

maciej-kisiel

I took a brief look at your PR and I believe we could utilize the oauth2 library more aggressively.

Please also take a look at my PR/proposal for client-side OAuth at #785. I think this PR could be expressed with the proposed abstractions, but your OAuth expertise would make the feedback valuable.

maciej-kisiel · 2026-02-11T12:48:50Z

oauthex/jwt_bearer.go

+
+// JWTBearerResponse represents the response from a JWT Bearer grant request
+// per RFC 7523. This uses the standard OAuth 2.0 token response format.
+type JWTBearerResponse struct {


Could https://pkg.go.dev/golang.org/x/oauth2#Token be used for this?

Yes, changed to oauth2.Token.

maciej-kisiel · 2026-02-11T12:50:03Z

oauthex/jwt_bearer.go

+}
+
+// JWTBearerError represents an error response from a JWT Bearer grant request.
+type JWTBearerError struct {


Could https://pkg.go.dev/golang.org/x/oauth2#RetrieveError be used for this?

Yes, changed to oauth2.RetrieveError.

maciej-kisiel · 2026-02-11T12:53:31Z

oauthex/jwt_bearer.go

+//		"mcp-client-secret",
+//		nil,
+//	)
+func ExchangeJWTBearer(


It feels like https://pkg.go.dev/golang.org/x/oauth2#Config.Exchange could be used to replicate the behavior of the function. Is there any reason not to use it?

oauth2#Config.Exchange always expect a code which we don't have in our Token Ecxhange. IdPs can reject the request if we don't pass code or pass it as an empty string.

IdPs can reject the request if we don't pass code or pass it as an empty string.

I don't think that should happen. Based on RFC 6749, Section 3.2:

Parameters sent without a value MUST be treated as if they were
omitted from the request. The authorization server MUST ignore
unrecognized request parameters.

I did a sample test and you're right. Changed to use Config.Exchange

oauthex/oauth2.go

maciej-kisiel · 2026-02-11T13:05:17Z

oauthex/token_exchange.go

+//	}
+//
+//	resp, err := ExchangeToken(ctx, idpTokenEndpoint, req, clientID, clientSecret, nil)
+func ExchangeToken(


It looks like https://pkg.go.dev/golang.org/x/oauth2#Config.Exchange can be used for Token Exchange as well? golang/oauth2#409

You're right. But it is the same comment as above.

Also, the Token struct don't have issued_token_type which is required to indicate the type of the token.

Also, the Token struct don't have issued_token_type which is required to indicate the type of the token.

I believe it could be accessible via Token.Extra, no?

Yes. Extracted issued_token_type from Token.Extra here.

maciej-kisiel · 2026-02-11T13:06:20Z

oauthex/token_exchange.go

+
+// TokenExchangeResponse represents the response from a token exchange request
+// per RFC 8693 Section 2.2.
+type TokenExchangeResponse struct {


Same comments as in oauthex/jwt_bearer.go apply to the request and error types.

Yes, changed to oauth2.

maciej-kisiel · 2026-03-03T14:33:57Z

Hi @radar07! I have recently merged #785 which I wrote about a few comments above. I think it's a good time to see if you could fit your desired auth flow into the OAuthHandler interface. I believe the Enterprise Managed authorization, as defined by the ext-auth repository should just expose a new implementation of this interface, just as AuthorizationCodeHandler implements the main MCP flow.

I would also ask you to implement this handler and put all the related helper files in a new sub-package of the auth package called extauth to make it clear that the functionality comes from an extension and is subject to different freshness guarantees.

If there is any logic from authorization_code.go that you would like to reuse, feel free to do so. We can move it to a more generic file in the future.

Thanks for working on this project!

radar07 · 2026-03-09T10:04:10Z

@maciej-kisiel Thanks for the feedback. I made the changes as you suggested. Could you please take a look again?

maciej-kisiel

I didn't manage to look at all files, I'll continue tomorrow.

In general I still believe we can use the oauth2 package more to reduce the amount of code to maintain. This should be an implementation detail, so we can always go back to custom logic if oauth2 stops being sufficient.

I think I would also simplify the API for OIDC login, to be similar to AuthorizationCodeHandler. Consistency would be an additional plus.

maciej-kisiel · 2026-03-10T11:31:11Z

auth/extauth/enterprise_handler.go

+type IDTokenFetcher func(ctx context.Context) (string, error)
+
+// EnterpriseHandlerConfig is the configuration for [EnterpriseHandler].
+type EnterpriseHandlerConfig struct {


Could we document which fields are required and which are optional in their doc comments?

maciej-kisiel · 2026-03-10T11:39:23Z

auth/extauth/enterprise_handler.go

+	defer func() {
+		if resp != nil && resp.Body != nil {
+			io.Copy(io.Discard, resp.Body)
+			resp.Body.Close()
+		}
+	}()


Suggested change

defer func() {

if resp != nil && resp.Body != nil {

io.Copy(io.Discard, resp.Body)

resp.Body.Close()

}

}()

defer resp.Body.Close()

defer io.Copy(io.Discard, resp.Body)

I think we can assume that the response is correctly passed. Good idea with draining Body, could you also apply it in authorization_code.go?

maciej-kisiel · 2026-03-10T11:42:28Z

auth/enterprise_auth.go

+//	}
+//
+//	// Use accessToken to call MCP Server APIs
+func EnterpriseAuthFlow(


Do we still need this if we have the EnterpriseHandler?

This uses OAuthHandler and allows users to use the Enterprise Auth Flow without the MCP imports. However, if we prefer keeping only the handler, we can remove this.

maciej-kisiel · 2026-03-10T11:46:54Z

auth/enterprise_auth.go

+
+// GetAuthServerMetadatForIssuer fetches authorization server metadata for the given issuer URL.
+// It tries standard well-known endpoints (OAuth 2.0 and OIDC) and returns the first successful result.
+func GetAuthServerMetadatForIssuer(ctx context.Context, IssuerURL string, httpClient *httpClient) (*oauthex.AuthServerMeta, error) {


It would be good to align it with authorization_code.go's getAuthServerMetadata. It can be generalized to not be a method on AuthorizationCodeHandler, but receive the URL as parameter instead of PRM and the client as a parameter instead of using the receiver. It should probably be moved to a different file, maybe something like shared.go?

Moved the code to shared.go (which can be renamed if needed). Also, the getAuthServerMetadata method has a different fallback behavior. I want to know your thoughts.

maciej-kisiel · 2026-03-10T11:50:01Z

auth/extauth/oidc_login.go

Please move this file inside extauth/, it is Enterprise flow specific.

maciej-kisiel · 2026-03-10T15:35:34Z

auth/oidc_login.go

+
+// generateCodeChallenge generates the PKCE code challenge from the verifier
+// using SHA256 per RFC 7636 Section 4.2.
+func generateCodeChallenge(verifier string) string {


https://pkg.go.dev/golang.org/x/oauth2#S256ChallengeFromVerifier

maciej-kisiel · 2026-03-10T15:37:08Z

auth/oidc_login.go

+
+// generateState generates a cryptographically random state parameter
+// for CSRF protection per RFC 6749 Section 10.12.
+func generateState() (string, error) {


Could https://pkg.go.dev/crypto/rand#Text be used here?

maciej-kisiel · 2026-03-10T15:47:13Z

auth/extauth/oidc_login.go

+	ExpiresAt int64
+}
+
+// InitiateOIDCLogin initiates an OIDC Authorization Code flow with PKCE.


Do you see a situation occurring of InitiateOICDLogin not being used with CompleteOIDCLogin? If not, maybe we could be more opinionated and implement the whole flow as a single function that just takes the "direct user to authorization URL and return the authorization result" as a functional argument, similar to how AuthorizationCodeHandlerConfig takes AuthorizationCodeFetcher?

In general this flow looks very similar to the normal authorization code flow, so maybe we could even reuse some of the data structures? Do you see a risk of the OAuth flow and the OIDC flow diverging in the future?

maciej-kisiel · 2026-03-10T15:49:14Z

auth/oidc_login.go

+}
+
+// buildAuthorizationURL constructs the OIDC authorization URL.
+func buildAuthorizationURL(


Have you considered reusing https://godoc.corp.google.com/pkg/google3/third_party/golang/oauth2/oauth2#Config.AuthCodeURL? I believe it supports all that's needed here.

Yes, right! Used oauth2.Config

maciej-kisiel · 2026-03-10T15:58:00Z

auth/oidc_login.go

+}
+
+// exchangeAuthorizationCode exchanges the authorization code for tokens.
+func exchangeAuthorizationCode(


I think https://godoc.corp.google.com/pkg/google3/third_party/golang/oauth2/oauth2#Config.Exchange could be used here and if you would follow the suggestion to make the whole OIDC a single function, you could even reuse the oauth2.Config.

I see what you mean. Good call.

maciej-kisiel

Few more comments. I looked at all Go files, excluding the tests. I will take a look at them when we align on the main logic.

maciej-kisiel · 2026-03-11T11:09:40Z

oauthex/id_jag.go

+//	}
+//	fmt.Printf("Subject: %s\n", claims.Subject)
+//	fmt.Printf("Expires: %v\n", claims.Expiry())
+func ParseIDJAG(jwt string) (*IDJAGClaims, error) {


Maybe we can use the golang-jwt/jwt library as an implementation detail for parsing to not replicate the logic?

Also, is this function used anywhere?

I added this in case if any one wants to verify the claims of the JWT. But, I believe it is not needed for this. Please let me know what you think.

maciej-kisiel · 2026-03-11T11:20:51Z

oauthex/jwt_bearer.go

+//		"mcp-client-secret",
+//		nil,
+//	)
+func ExchangeJWTBearer(


IdPs can reject the request if we don't pass code or pass it as an empty string.

I don't think that should happen. Based on RFC 6749, Section 3.2:

Parameters sent without a value MUST be treated as if they were
omitted from the request. The authorization server MUST ignore
unrecognized request parameters.

maciej-kisiel · 2026-03-11T11:23:55Z

oauthex/token_exchange.go

+//	}
+//
+//	resp, err := ExchangeToken(ctx, idpTokenEndpoint, req, clientID, clientSecret, nil)
+func ExchangeToken(


Also, the Token struct don't have issued_token_type which is required to indicate the type of the token.

I believe it could be accessible via Token.Extra, no?

- Adds the Token Exchange (RFC 8693) for Enterprise-Managed Authorization

# Conflicts: # oauthex/oauth2.go

radar07 · 2026-03-16T07:53:21Z

@maciej-kisiel Thank you so much for taking the time to review this PR and your valuable feedback. I have made the changes as you suggested and need your suggestions on the changes.

maciej-kisiel reviewed Feb 11, 2026

View reviewed changes

This was referenced Feb 18, 2026

feat: Add Enterprise Managed Authorization (SEP-990) support aniket-okta/csharp-sdk#1

Open

feat: Add Enterprise Managed Authorization (SEP-990) support modelcontextprotocol/csharp-sdk#1305

Open

radar07 requested a review from maciej-kisiel February 24, 2026 15:48

maciej-kisiel requested changes Mar 3, 2026

View reviewed changes

radar07 force-pushed the enterprise-managed-authorization branch from b3cba20 to f94e462 Compare March 4, 2026 10:48

maciej-kisiel requested changes Mar 10, 2026

View reviewed changes

maciej-kisiel reviewed Mar 11, 2026

View reviewed changes

radar07 added 13 commits March 15, 2026 10:30

feat: add token exchange flow

160a55f

- Adds the Token Exchange (RFC 8693) for Enterprise-Managed Authorization

feat: add jwt bearer flow with id-jag

6b57384

feat: add id-jag+jwt parsing and enterprise auth

adaaecb

chore: use auth server metadata for token endpoints

5a52c5e

# Conflicts: # oauthex/oauth2.go

feat: fetch jwks for jwt signature verification

e070a87

feat: add id-jag validation for mcp servers

a0e9031

feat: add oidc login for sso

35c0565

docs: add docs for enterprise authorization

8b7ba7a

chore: remove id jag verification

b7433c3

chore: rename MCPResourceURL to MCPResourceURI

6b8bfdc

feat: use oauth2 for token structs

897455b

chore: update auth ext package

b6161af

chore: update header files with current year

0649bcd

radar07 force-pushed the enterprise-managed-authorization branch 4 times, most recently from 24931e7 to a4fd173 Compare March 15, 2026 17:36

refactor: use oauth2 package and remove unused functions

d5b2a5d

radar07 force-pushed the enterprise-managed-authorization branch from a4fd173 to d5b2a5d Compare March 15, 2026 17:46

radar07 requested a review from maciej-kisiel March 16, 2026 07:53

teemow mentioned this pull request Mar 16, 2026

Evaluate enterprise IdP integration (SEP-990) for SSO across MCP servers giantswarm/muster#507

Open

9 tasks

prachi-okta mentioned this pull request Mar 16, 2026

Feature/enterprise managed authorization modelcontextprotocol/java-sdk#871

Open

9 tasks

Conversation

radar07 commented Jan 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

maciej-kisiel commented Jan 30, 2026

Uh oh!

radar07 commented Jan 31, 2026

Uh oh!

radar07 commented Feb 3, 2026

Uh oh!

maciej-kisiel left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

maciej-kisiel commented Mar 3, 2026

Uh oh!

radar07 commented Mar 9, 2026

Uh oh!

maciej-kisiel left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

radar07 commented Jan 30, 2026 •

edited

Loading