-
Notifications
You must be signed in to change notification settings - Fork 6
[HTTP AUTH SPIKE - do not merge yet] Add HTTP transport with JWT middleware and configuration updates #61
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.
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
base: main
Are you sure you want to change the base?
Conversation
How restricted is |
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 (meanwhile I'll convert this PR to draft as well, thanks for the security ping😂) |
There was a problem hiding this 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") { |
There was a problem hiding this comment.
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") |
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
Bearer realm=toBearer resource_metadata=[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.