Problem
The AuthBridge go-processor (ext_proc) performs outbound token exchange (RFC 8693) by taking the Authorization header from outbound requests and exchanging it for a new token scoped to the target tool. However, when the outbound request has no Authorization header, the ext_proc skips token injection entirely, and the request reaches the target tool without authentication.
This happens because many agent frameworks (including the A2A SDK) do not propagate the inbound Bearer token to outbound tool calls. The agent code assumes "AuthBridge handles outbound authentication transparently", but the ext_proc currently requires an existing token to exchange.
Observed behavior
[Token Exchange] Configuration loaded, attempting token exchange
[Token Exchange] Client ID: spiffe://localtest.me/ns/team1/sa/git-issue-agent
[Token Exchange] Target Audience: github-tool
[Token Exchange] Target Scopes: openid github-tool-aud github-full-access
[Token Exchange] No Authorization header found
The tool then rejects the request:
missing required Authorization header (401)
Expected behavior
When no Authorization header is present on an outbound request, the ext_proc should fall back to a client_credentials grant using the agent's shared credentials (/shared/client-id.txt + /shared/client-secret.txt), obtain a token, and inject it as the Authorization header.
Proposed solution
In go-processor/main.go, when authHeader == "" on outbound:
- Read
/shared/client-id.txt and /shared/client-secret.txt (already available from client-registration sidecar)
- Perform a
client_credentials grant to the TOKEN_URL with the target audience and scopes
- Inject the resulting token as
Authorization: Bearer <token>
- Log as
[Client Credentials] to distinguish from [Token Exchange]
Trade-offs
| Approach |
Preserves user identity (sub) |
Works without agent changes |
| Token exchange (current) |
Yes |
No - agent must forward token |
| Client credentials fallback (proposed) |
No - uses agent identity |
Yes - fully transparent |
Both approaches should coexist: prefer token exchange when an Authorization header IS present (preserves user identity), fall back to client_credentials when it is not.
Longer term
Agents should forward the inbound Bearer token to outbound calls so that token exchange can preserve the end user's sub claim. This requires A2A SDK or agent framework changes. The client_credentials fallback ensures AuthBridge works transparently regardless.
Related
Problem
The AuthBridge go-processor (ext_proc) performs outbound token exchange (RFC 8693) by taking the Authorization header from outbound requests and exchanging it for a new token scoped to the target tool. However, when the outbound request has no Authorization header, the ext_proc skips token injection entirely, and the request reaches the target tool without authentication.
This happens because many agent frameworks (including the A2A SDK) do not propagate the inbound Bearer token to outbound tool calls. The agent code assumes "AuthBridge handles outbound authentication transparently", but the ext_proc currently requires an existing token to exchange.
Observed behavior
The tool then rejects the request:
Expected behavior
When no Authorization header is present on an outbound request, the ext_proc should fall back to a client_credentials grant using the agent's shared credentials (
/shared/client-id.txt+/shared/client-secret.txt), obtain a token, and inject it as the Authorization header.Proposed solution
In
go-processor/main.go, whenauthHeader == ""on outbound:/shared/client-id.txtand/shared/client-secret.txt(already available from client-registration sidecar)client_credentialsgrant to the TOKEN_URL with the target audience and scopesAuthorization: Bearer <token>[Client Credentials]to distinguish from[Token Exchange]Trade-offs
Both approaches should coexist: prefer token exchange when an Authorization header IS present (preserves user identity), fall back to client_credentials when it is not.
Longer term
Agents should forward the inbound Bearer token to outbound calls so that token exchange can preserve the end user's
subclaim. This requires A2A SDK or agent framework changes. The client_credentials fallback ensures AuthBridge works transparently regardless.Related