Skip to content

Conversation

@keremgocen
Copy link
Contributor

@keremgocen keremgocen commented Oct 13, 2025

  • adds temporary helper flags
  • ResourceIdentifier in config now we try to validate it in JWT's registeredClaims (audience in auth provider)
  • fixes RFC 9728, the protected resource metadata header from Bearer realm= to Bearer resource_metadata=
  • adds native corsMiddleware to allow all origins, we should disable this in main I think?
  • updates golangci-lint config to complain about unused stuff and todo notes
  • adds RBAC on tool calls via external auth roles and user permissions in the JWT

[Note] We are not planning to merge the extra auth flow endpoints apart from the changes in the handleProtectedResourceMetadata. This PR is for the rest of the team to test the auth changes locally.

@irene221b
Copy link

	// Redirect to Auth0 callback endpoint (typically not used, but for completeness)
	auth0URL := fmt.Sprintf("https://%s/login/callback?%s", s.config.Auth0Domain, r.URL.RawQuery)

How restricted is r.URL.RawQuery is? Can someone set it to ?#redirect=www.fake-target.site to achieve a redirect here?

@keremgocen
Copy link
Contributor Author

How restricted is r.URL.RawQuery is? Can someone set it to ?#redirect=www.fake-target.site to achieve a redirect here?

Good call, as of now, it looks like both /authorize and /callback handlers are vulnerable to open redirect attacks, but we are not planning to merge these changes to main.

According to the MCP authorisation spec I was only expecting to implement the GET /.well-known/oauth-protected-resource endpoint, which returns the protected resource metadata per RFC9728. But I noticed vscode MCP client is actually calling these auth flow endpoints on the MCP server as well (it should call the auth server directly). We are trying to figure out why and if there's anything missing with our config, so hopefully everything in this PR apart from the resource metadata endpoint will be deleted.

(meanwhile I'll convert this PR to draft as well, thanks for the security ping😂)

@keremgocen keremgocen marked this pull request as draft October 14, 2025 09:29
@keremgocen keremgocen changed the title Add HTTP transport with Auth0 middleware and configuration updates [do not merge yet] Add HTTP transport with Auth0 middleware and configuration updates Oct 14, 2025
@keremgocen keremgocen changed the base branch from mcp-http-auth0-spike to main October 15, 2025 12:57
@keremgocen keremgocen changed the title [do not merge yet] Add HTTP transport with Auth0 middleware and configuration updates [HTTP AUTH SPIKE - do not merge yet] Add HTTP transport with Auth0 middleware and configuration updates Oct 15, 2025
@keremgocen keremgocen changed the title [HTTP AUTH SPIKE - do not merge yet] Add HTTP transport with Auth0 middleware and configuration updates [HTTP AUTH SPIKE - do not merge yet] Add HTTP transport with JWT middleware and configuration updates Oct 17, 2025
Copy link
Contributor

@MacondoExpress MacondoExpress left a comment

Choose a reason for hiding this comment

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

I have to test it with an IDP, but from reading seem the flow we are expecting, all the comments are nitpicky comments!

}

// Handle help flag
if len(os.Args) > 1 && (os.Args[1] == "-h" || os.Args[1] == "--help") {
Copy link
Contributor

Choose a reason for hiding this comment

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

In the case we want to merge this, I would move the flags logic outside the main file

func extractPermissionsFromClaims(validatedClaims *validator.ValidatedClaims) []string {
customClaims, ok := validatedClaims.CustomClaims.(*CustomClaims)
if !ok {
log.Printf("⚠ Failed to extract custom claims")
Copy link
Contributor

Choose a reason for hiding this comment

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

I would remove these icons as they may create unnecessary friction when integrating with external services

// Construct the protected resource metadata URL per RFC 9728
// This tells clients where to discover this resource server's configuration
// NOTE: This should point to THIS server's metadata endpoint, not Auth0's
metadataURL := "http://" + s.config.HTTPHost + ":" + s.config.HTTPPort + "/.well-known/oauth-protected-resource"
Copy link
Contributor

Choose a reason for hiding this comment

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

Not sure if it's worth changing or adding a FIXME/TODO comment but in the future this URL could be:
"https://resource.example.com/.well-known/oauth-protected-resource" - therefore with a different protocol and optional port

// NOTE: This should point to THIS server's metadata endpoint, not Auth0's
metadataURL := "http://" + s.config.HTTPHost + ":" + s.config.HTTPPort + "/.well-known/oauth-protected-resource"

// Build WWW-Authenticate header value per RFC 6750 Section 3
Copy link
Contributor

Choose a reason for hiding this comment

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

Extremely nitpick, but if you think it could be helpful (I don't) the format of WWW-Authenticate is defined by the RFC 6750 but the resource_metadata value is defined by the https://datatracker.ietf.org/doc/html/rfc9728/#section-5.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants