Learn A2A - Authentication & Security

#Introduction

In episode 8 you could send structured data between agents neatly. But there's a question we haven't answered: is everyone allowed to call our agent? An agent exposing a JSON-RPC endpoint without authentication is just an open door — anyone can send tasks, read results, or burn through LLM quota. This episode closes that gap.

This episode's roadmap: we start with why agent-level authentication matters, then dissect the authentication field on the Agent Card, the OAuth 2.1 flow, the API key and JWT alternatives, and finally signed agent cards for building trust between agents.

#Why Agent-Level Authentication Matters

Recall the opaque agent principle from episode 2: an agent is a peer service that only communicates through the task lifecycle. Because its internals are hidden, incoming access can only be controlled from the outside — and that means authentication must be part of the protocol itself, not a random policy on each server.

Agent-level authentication also enables capability-based authorization. An agent reading internal data can restrict who may send certain tasks; a public agent can distinguish internal and external clients. That's why the Agent Card carries an authentication declaration — so prospective clients know exactly how to "get in" before sending a single request.

#The authentication Field on the Agent Card

The A2A specification puts the authentication requirement in the authentication field on the Agent Card. This field contains a list of schemes — each describing one mechanism the server supports:

{
  "agentName": "Analisis Lead",
  "url": "https://lead-agent.example.com/",
  "authentication": {
    "schemes": [
      {
        "type": "oauth2",
        "name": "oauth-vendor",
        "credentialFormat": "bearer",
        "authorizationServer": {
          "url": "https://auth.example.com/.well-known/oauth-authorization-server"
        }
      },
      {
        "type": "apiKey",
        "name": "api-key",
        "location": "header",
        "in": "Authorization"
      }
    ]
  }
}

Clients read this list to determine which mechanism they can use. The three most common types: oauth2 with a full flow, apiKey for static tokens, and jwt for signed tokens carrying claims.

#The OAuth 2.1 Flow

For enterprise agents, OAuth 2.1 is the primary choice. Compared to OAuth 2.0, version 2.1 removes several shortcuts that were prone to misuse — for example, the authorization code flow only via PKCE — and that's what the A2A ecosystem adopts.

The flow in brief:

1. Discover. The client fetches the Agent Card and finds the oauth2 scheme along with the authorizationServer URL.
2. Metadata. The client opens that URL to get the token endpoint, supported audience, and additional parameters.
3. Get a token. For service-to-service interaction (no user), the right flow is client credentials: the client exchanges its client_id and secret for an access token.
4. Send the task. Every JSON-RPC request carries the token, usually in the Authorization header in Bearer format.

curl -X POST https://lead-agent.example.com/ \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer TOKEN_AKSES" \
  -d '{"jsonrpc":"2.0","id":1,"method":"message/send","params":{"message":{"role":"user","parts":[{"kind":"text","text":"Analisis lead"}]}}}'

The main advantage of OAuth is delegation and rotation. Tokens can have short lifetimes, rotate automatically, and be revoked without touching static credentials on many servers. This is the right choice when an agent is called by many orchestrators across teams.

#API Key and JWT

Not every case needs OAuth. For simple integrations between internal agents, an API key is lighter: the client sends one static string, and the server matches it against its own key store. The apiKey scheme in the Agent Card tells the client where the key goes — usually the Authorization header or X-API-Key.

JWT sits in between: the server verifies the token signature with a public key, without needing to store sessions or match a key per client. Claims inside the token — for example, tenant or access level — can be read directly by the server for authorization.

Whatever the mechanism, the rule of thumb is the same: always HTTPS. A token sent over plain HTTP is the same as a token displayed in public.

#Signed Agent Card: Identity & Integrity Verification

Authentication answers "who are you", but not yet "is the card you're holding really yours". A2A v1.0 answers this with the signed agent card — signing the card so clients can verify identity and capability integrity before trusting its contents.

A signed card carries a security object with signedCard, containing the signature and the verification key in JWKS format:

{
  "agentName": "Analisis Lead",
  "version": "1.0.0",
  "security": {
    "signedCard": {
      "signature": "eyJhbGciOiJFUzI1NiIsImtpZCI6ImsyMDI2Iiwi",
      "signingKey": {
        "jwks": {
          "keys": [
            { "kty": "EC", "crv": "P-256", "kid": "kunci-2026", "x": "AZ...", "y": "Yz..." }
          ]
        }
      }
    }
  }
}

When downloading the card during discovery (episode 3), the client performs layered verification:

1. Get the signature and the signingKey key from the security field.
2. Verify the signature against the card content with the public key from JWKS.
3. If the signature is valid, the card is considered to come from the key owner — the capability contents can be trusted.
4. Match the expected identity, for example the domain or partner organization.

The resulting trust model is agent-to-agent: each agent verifies its counterpart directly, without needing a central authority. This is what lets a network of hundreds of organizations — like the 150+ partner ecosystem under the Linux Foundation — trust each other without a single point of control.

#Conclusion

Episode 9 locks down access to your agents: the authentication field on the Agent Card declares the supported mechanisms — OAuth 2.1 for delegation and token rotation, API key for lightweight integrations, JWT for stateless claim-carrying tokens. And the signed agent card in A2A v1.0 provides identity and capability integrity verification through digital signatures, building direct trust between agents.

Here's the core takeaway:

• Agent authentication starts with the authentication field declaration on the Agent Card with a list of schemes.
• OAuth 2.1 is used for enterprise scenarios: metadata discovery, client credentials, bearer tokens in the Authorization header.
• API key for simple internal integrations; JWT for large-scale distribution with built-in claims.
• Always HTTPS and rotate credentials; short-lived tokens are safer.
• Signed agent cards verify signatures with JWKS, and trust is built through controlled public key distribution.

Authentication solves one problem, but opens new questions in the enterprise environment: how does one agent serve many clients with different contexts and isolation, and how do two agents with different protocol versions keep communicating? In episode 10 we discuss Multi-tenancy & Version Negotiation (v1.0). See you there!