Glossary · Protocols and standards

OAuth 2.0

The IETF authorization framework (RFC 6749) in which a client gets a scoped access token from an authorization server. A2A agents declare it in securitySchemes.

OAuth 2.0 is the IETF authorization framework, RFC 6749 (October 2012), in which a client obtains an access token from an authorization server and presents it to a resource server, either with a resource owner’s approval or on its own behalf.

Roles and grants. RFC 6749 defines four roles: resource owner, client, authorization server and resource server. The client gets a token through a grant. The authorization code grant sends a user to approve access in a browser. The client credentials grant covers machine-to-machine calls with no user present. The device authorization grant (RFC 8628) serves devices and command-line tools where the user approves on a second screen. Scopes limit what a token allows.

Current practice. RFC 9700, the OAuth 2.0 Security Best Current Practice (January 2025), says the resource owner password credentials grant must not be used, says clients should not use the implicit grant, and requires PKCE for public clients. OAuth 2.1 consolidates these rules into one document but is still an Internet-Draft, at revision 16 in September 2026.

In A2A. An agent declares OAuth in its Agent Card as an oauth2SecurityScheme inside securitySchemes. Version 1.0 offers authorization code (with a pkceRequired flag), client credentials and device code flows. The implicit and password flows remain in the proto only as deprecated fields. The optional oauth2MetadataUrl points to the server’s RFC 8414 metadata. The client obtains tokens out of band and sends them with every request, usually as Authorization: Bearer. Illustrative:

{
  "securitySchemes": {
    "partnerOAuth": {
      "oauth2SecurityScheme": {
        "flows": {
          "clientCredentials": {
            "tokenUrl": "https://auth.example.com/oauth/token",
            "scopes": {"orders:read": "Read order status"}
          }
        },
        "oauth2MetadataUrl": "https://auth.example.com/.well-known/oauth-authorization-server"
      }
    }
  },
  "securityRequirements": [{"schemes": {"partnerOAuth": {"list": ["orders:read"]}}}]
}

Neighbouring terms. OpenID Connect adds user identity on top of OAuth 2.0. Access tokens are often JWTs. A token shows what the authorization server granted the client. The scope and revocation of any extra authorization an agent obtains during a task are left by A2A to implementations and extensions (section 7.6.4).

Sources

  1. RFC 6749: The OAuth 2.0 Authorization Framework (accessed )
  2. RFC 9700: Best Current Practice for OAuth 2.0 Security (accessed )
  3. RFC 8628: OAuth 2.0 Device Authorization Grant (accessed )
  4. RFC 8414: OAuth 2.0 Authorization Server Metadata (accessed )
  5. The OAuth 2.1 Authorization Framework (draft-ietf-oauth-v2-1) (accessed )
  6. A2A protocol definition (a2a.proto): OAuth2SecurityScheme, OAuthFlows (accessed )
  7. A2A Protocol Specification, section 7.3: Client Authentication Process (accessed )
  8. A2A Protocol Specification, section 7.6: In-Task Authorization (accessed )