Skip to content

Wolo/auth consent gcp#1142

Draft
wolo-lab wants to merge 8 commits into
wolo/auth-consentfrom
wolo/auth-consent-gcp
Draft

Wolo/auth consent gcp#1142
wolo-lab wants to merge 8 commits into
wolo/auth-consentfrom
wolo/auth-consent-gcp

Conversation

@wolo-lab

Copy link
Copy Markdown
Contributor

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):

  • Closes: #issue_number
  • Related: #issue_number

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:

  • I have added or updated unit tests for my change.
  • All unit tests pass locally.

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

  • I have read the CONTRIBUTING.md document.
  • I have performed a self-review of my own code.
  • I have commented my code, particularly in hard-to-understand areas.
  • I have added tests that prove my fix is effective or that my feature works.
  • New and existing unit tests pass locally with my changes.
  • I have manually tested my changes end-to-end.
  • Any dependent changes have been merged and published in downstream modules.

Additional context

Add any other context or screenshots about the feature request here.

@wolo-lab
wolo-lab force-pushed the wolo/auth-consent branch from dcca456 to 75e4317 Compare July 11, 2026 09:57
@wolo-lab
wolo-lab force-pushed the wolo/auth-consent-gcp branch from 360105c to ef4a912 Compare July 11, 2026 21:32
@wolo-lab
wolo-lab force-pushed the wolo/auth-consent branch from 75e4317 to 2ebe100 Compare July 11, 2026 21:46
@wolo-lab
wolo-lab force-pushed the wolo/auth-consent-gcp branch from ef4a912 to 0675063 Compare July 11, 2026 21:49
@wolo-lab
wolo-lab force-pushed the wolo/auth-consent branch from 2ebe100 to 3ed5bbe Compare July 11, 2026 22:34
wolo-lab added 8 commits July 11, 2026 22:34
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
wolo-lab force-pushed the wolo/auth-consent-gcp branch from 0675063 to d68a62f Compare July 11, 2026 22:39
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.

1 participant