Wolo/auth consent gcp#1142
Draft
wolo-lab wants to merge 8 commits into
Draft
Conversation
wolo-lab
force-pushed
the
wolo/auth-consent
branch
from
July 11, 2026 09:57
dcca456 to
75e4317
Compare
wolo-lab
force-pushed
the
wolo/auth-consent-gcp
branch
from
July 11, 2026 21:32
360105c to
ef4a912
Compare
wolo-lab
force-pushed
the
wolo/auth-consent
branch
from
July 11, 2026 21:46
75e4317 to
2ebe100
Compare
wolo-lab
force-pushed
the
wolo/auth-consent-gcp
branch
from
July 11, 2026 21:49
ef4a912 to
0675063
Compare
wolo-lab
force-pushed
the
wolo/auth-consent
branch
from
July 11, 2026 22:34
2ebe100 to
3ed5bbe
Compare
A3a added the generic adk_request_credential round-trip, but nothing triggered it for MCP: mcptoolset applies auth in the transport's RoundTripper, which cannot start a consent flow (it has no function call id) — and the MCP SDK drops the underlying error chain (streamable.go wraps the transport error with %v), so a provider's auth.ErrConsentRequired never reaches the tool through CallTool. This wires the interactive path for MCP: - mcptoolset passes Config.Auth to each tool and, before calling the server, probes the provider. If it returns auth.ErrConsentRequired, the tool calls ctx.RequestCredential (pausing the run for consent) and returns the new tool.ErrCredentialRequired sentinel. On success the provider caches the credential, so the RoundTripper reuses it on the actual call — no extra network round-trip for the common (GCP) case. - ctx.AuthResponse guards the resume: once the user has consented, a provider that still cannot mint a credential fails instead of looping. - tool.ErrCredentialRequired is the credential analog of ErrConfirmationRequired; retryandreflect skips it like the other HITL sentinels. The GCP provider already re-resolves after consent and caches, so no auth/gcp change is needed. SessionStateCredentialStore is intentionally deferred: the managed GCP flow re-resolves from the service, so it has no consumer here (it belongs with generic OAuth, A4). Testing: go build, go test -race -shuffle=on ./..., golangci-lint run, go mod tidy -diff — all green (one unrelated, pre-existing a2a cancellation flake in agent/remoteagent/v2 that passes on rerun). New tests cover the consent request, proceed-after-consent, the no-loop guard, and the no-provider path.
Illustrate wiring per-user Google Cloud credentials into an MCP toolset via mcptoolset.Config.Auth = gcp.NewProvider(...). Comments walk through both the non-interactive path (server-side / 2-legged / ADC, applied transparently by the transport RoundTripper) and the interactive 3-legged consent flow, where the run emits adk_request_credential and resumes the tool once the user consents. The example is a buildable template; the live consent flow requires a real MCP server and GCP auth resource.
Add a self-contained, offline test proving mcptoolset.Config.Auth authenticates outgoing MCP requests end-to-end. A local streamable-HTTP MCP server requires a bearer token on every request — tool listing and calling alike — mirroring adk-python's contributing/samples/mcp/mcp_toolset_auth/oauth_mcp_server.py. With auth.StaticToken the credential is attached (via the transport RoundTripper) and both listing and calling succeed; without it the server rejects with 401. No API key or external services required, so it runs deterministically in CI.
Generalize the offline A2A auth test into a shared helper and add an API-key case alongside the existing bearer one, so A2AConfig.Auth is exercised for both the HTTP/OAuth2 (Authorization: Bearer) and API-key (named header) security schemes a card can declare. Fully offline: a local a2asrv records the request headers and the test asserts the credential the interceptor attached.
Make the local authed MCP server validate a caller-supplied predicate and run the demo table-driven over both auth.StaticToken (bearer) and auth.APIKey (header). Each case proves Config.Auth attaches the credential to tool listing and calling, and that requests without a provider are rejected with 401 — all offline.
Extend the MCP auth example to build the provider from AUTH_MODE, showing how each built-in provider wires into mcptoolset.Config.Auth: GCP, header API key, static bearer, ADC, and service account. Service account and API key are the newly illustrated cases; the GCP interactive (3-legged) flow was already covered.
…r MCP Add an offline case where a local OAuth2 token endpoint implements the client_credentials grant: x/oauth2/clientcredentials mints a bearer from the client id/secret, auth.TokenSourceProvider caches it, and the authed MCP server accepts the resulting Authorization header. Factor the list+call assertion into a shared callWeatherTool helper reused by the bearer/API-key cases too.
Extend AUTH_MODE with oauth2cc, wiring 2-legged OAuth into mcptoolset.Config.Auth via x/oauth2/clientcredentials + auth.TokenSourceProvider.
wolo-lab
force-pushed
the
wolo/auth-consent-gcp
branch
from
July 11, 2026 22:39
0675063 to
d68a62f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Please ensure you have read the contribution guide before creating a pull request.
Link to Issue or Description of Change
1. Link to an existing issue (if applicable):
2. Or, if no issue exists, describe the change:
If applicable, please follow the issue templates to provide as much detail as
possible.
Problem:
A clear and concise description of what the problem is.
Solution:
A clear and concise description of what you want to happen and why you choose
this solution.
Testing Plan
Please describe the tests that you ran to verify your changes. This is required
for all PRs that are not small documentation or typo fixes.
Unit Tests:
Please include a summary of passed go test results.
Manual End-to-End (E2E) Tests:
Please provide instructions on how to manually test your changes, including any
necessary setup or configuration. Please provide logs or screenshots to help
reviewers better understand the fix.
Checklist
Additional context
Add any other context or screenshots about the feature request here.