JSON Web Token (JWT)

A JSON Web Token (JWT) is a compact, URL-safe way to pass claims between two parties, defined in RFC 7519 (May 2015), in which a JSON claims set is protected by a JWS signature or MAC, or encrypted with JWE.

Structure. A signed JWT in compact form is three base64url strings joined by periods: a header that names the algorithm and often a key ID (kid), the claims set, and the signature. RFC 7519 registers seven claim names: iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at) and jti (a unique token ID). Times are seconds since the Unix epoch. A decoded claims set, illustrative:

{"iss": "https://agent.example.com", "sub": "client-4821", "aud": "https://hooks.example.net", "iat": 1790445600, "exp": 1790445900, "jti": "0f8e6c1a-3b7d-4f21-9a55-2c1d7e9b4a10"}

Validating one. A signature check alone is not enough. RFC 8725, the JWT Best Current Practices, tells verifiers to accept only the algorithms they expect, validate every cryptographic operation, check the issuer and subject, check that the audience is theirs, and use explicit typing so one kind of JWT cannot be passed off as another.

In A2A. JWTs show up in several places:

• An Agent Card’s httpAuthSecurityScheme can set bearerFormat to JWT as a hint for bearer tokens.
• OpenID Connect ID tokens, used with openIdConnectSecurityScheme, are JWTs.
• The A2A guide to streaming and asynchronous operations describes an agent signing each push notification with a JWT. The token carries iss, aud, iat, exp, jti and the taskId, and the webhook verifies it against the agent’s JWKS, using jti to reject replays.

Agent Card signatures use JWS directly. They are not JWTs.

Neighbouring terms. JWS is the signature format underneath a signed JWT. A JWKS publishes the public keys that verifiers fetch by kid.