Repository navigation
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds support for exposing identity claims (sub, email, and email_verified) when validating opaque access tokens (MCP Auth mode) via Google's tokeninfo endpoint. It updates the JSON unmarshalling to handle Google's stringified boolean for email_verified, exposes these claims conditionally, adds comprehensive unit tests, and updates the documentation accordingly. I have no feedback to provide as there are no review comments.
…ess tokens
In MCP auth mode the google authService validates opaque access tokens via
Google's tokeninfo endpoint, but only returned aud and scope as claims. As a
result authenticated parameters using field: email or field: sub could not be
resolved ("no field named email in claims").
Decode sub, email and email_verified from the tokeninfo response and add them
to the claims. email is only exposed when email_verified is "true".
Refs googleapis#4049
a122e22 to
9ac2e68
Compare
This branch has not been deployed
2 participants
Description
In MCP Auth mode (
mcpEnabled: true), thegoogleauthService validates opaqueGoogle access tokens (
ya29...) through the tokeninfo endpoint. It only decodedaud,azpandscopefrom the response, so the claims map handed to toolscontained just
audandscope. Authenticated parameters that reademailorsub(authServices: [{name: ..., field: email}]) therefore failed for opaquetokens with:
Google ID tokens already work, because their full JWT payload is returned as
claims. This brings opaque tokens in line with that behavior.
Solution: decode
sub,emailandemail_verifiedfrom the tokeninforesponse and add them to the claims map.
email/email_verifiedare onlyexposed when tokeninfo reports
email_verifiedas"true", so an unverifiedaddress can't be used to populate parameters that drive access decisions. As
with ID tokens,
subandemailare only present when the token was grantedthe
openid/emailscopes. No config or behavior changes for tokens thatcarry no identity fields.
Impact:
field: email/field: subnow work for opaque access tokens inMCP Auth mode. No change for ID tokens, for the existing audience/scope
validation, or for non-MCP mode.
Testing
TestValidateMCPAuth_Opaque_Claims(verified email, unverified email,missing
email_verified, no identity fields). It fails without the change andpasses with it.
go test ./internal/auth/... ./internal/server/...andgolangci-lint run ./internal/auth/...pass. Package coverage forinternal/auth/googlegoes from 54.2% to 56.2%.token: a tool with
authServices: [{name: google-mcp, field: email}]nowreceives the caller's verified email.
TestGoogleOAuthValidationuses an ADC token, and exercising
emailend to end needs a token for a realuser account with the email scope. Happy to add one if you can suggest a
suitable credential for CI.
Docs: noted which claims are available for opaque tokens in
docs/en/documentation/configuration/authentication/google.md.PR Checklist
CONTRIBUTING.md
bug/issue
before writing your code! That way we can discuss the change, evaluate
designs, and agree on the general idea
review
!if this involve a breaking changeFixes #4049 🦕