google-gemini / google-gemini/gemini-cli
bug: A2A OpenID Connect config validates but cannot be constructed
- Dominant language
- TypeScript
- Stars
- 107k
- Forks
- 14.6k
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 45
Description
## What happened?
A2A OpenID Connect authentication is exposed as a supported public configuration and passes compatibility validation, but provider creation always throws `openIdConnect auth provider not yet implemented`.
Specifically:
- `packages/core/src/agents/auth-provider/types.ts:15-20` includes `openIdConnect` in `A2AAuthProviderType`.
- Lines 87-102 define `OpenIdConnectAuthConfig` and include it in `A2AAuthConfig`.
- `packages/core/src/agents/auth-provider/factory.ts:204-207` treats that config as compatible with an OpenID Connect agent-card security scheme.
- `packages/core/src/agents/auth-provider/factory.ts:85-87` nevertheless always throws when asked to construct it.
Tests currently verify that OIDC configuration matches an OIDC scheme, reinforcing the impression that this is a usable configuration.
## How can this be reproduced?
1. Define a remote A2A agent whose card declares an `openIdConnect` security scheme.
2. Supply an `A2AAuthConfig` with `type: openIdConnect`, a valid issuer URL, and client ID.
3. `validateAuthConfig()` returns valid.
4. Loading/connecting the agent calls `A2AAuthProviderFactory.create()` and fails unconditionally.
## What did you expect to happen?
Configuration accepted by the public type and validation layer should be constructible. If implementation is intentionally deferred, validation should reject it clearly before agent startup and documentation/types should not present it as operational support.
## Why this matters
Users configuring standards-compliant OIDC-protected remote agents receive a late runtime failure after configuration appears valid. It also makes it difficult for tooling to distinguish supported authentication from schema reserved for future use.
## Suggested direction
Either:
1. Implement OIDC discovery/token handling, potentially sharing the existing OAuth2 flow and token storage; or
2. Mark OIDC explicitly unsupported and reject it during validation until implementation is available.
Tests should cover the complete validate-to-create lifecycle rather than validation alone.
## Client information
Found by source audit on current `main`, commit `f47d6c6f7`. This is platform-independent A2A configuration behavior; `/about` output is not applicable.
Contributor guide
Research direction
Read packages/core/src/agents/auth-provider/types.ts:15-20 and 87-102, then inspect packages/core/src/agents/auth-provider/factory.ts:85-87 and 204-207 plus the existing OIDC validation tests. Determine whether OIDC should be implemented or rejected during validation, and cover the complete validate-to-create lifecycle so accepted configurations no longer fail unconditionally.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- authentication
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100