google-gemini / google-gemini/gemini-cli

bug: A2A OpenID Connect config validates but cannot be constructed

Open
#28,651 0 comments 0 reactions 0 assignees View on GitHub
area/security status/need-triage
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.