DEV Community: Marwa Sahli

The A2A protocol: how it works, step by step, and how it compares with MCP

Marwa Sahli — Thu, 05 Nov 2026 08:28:43 +0000

AI systems are no longer just a single model answering questions. We now build specialised agents (an HR agent, a booking agent, a code-review agent), often developed by different teams, on different frameworks (LangGraph, CrewAI, ADK, OpenAI Agents SDK…), and hosted by different providers. That raises a new question: how do these agents talk to each other?

That is the question A2A (Agent2Agent) answers. This article introduces the protocol, walks through how it works step by step, and then compares it with MCP (Model Context Protocol), with which it is often confused.

What is A2A?
History and governance
Key concepts
A three-layer architecture
How it works, step by step
Task lifecycle
Security
A2A vs MCP
Using A2A and MCP together
Current limitations and best practices
Conclusion

1. What is A2A?

A2A is an open specification that defines how independent AI agents:

discover each other (who can do what, and how to reach them),
delegate tasks to one another, including long-running, multi-step ones,
exchange data (text, JSON, files) securely,
track progress on work in flight (streaming, notifications).

The core idea: every agent is treated as a black box. A client agent does not need to know the remote agent's model, prompt, tools or memory. It hands over a task, the way you would hand a file to a colleague in another department, and gets a result back.

In one sentence: MCP connects an agent to its tools; A2A connects an agent to other agents.

2. History and governance

Date	Milestone
April 2025	Protocol announced by Google, with around fifty partners
June 2025	Project donated to the Linux Foundation, which now provides neutral governance
Summer 2025	Version 0.3: gRPC binding added, Agent Card signatures
March 2026	Stable version 1.0
2026	Production support in several platforms (Microsoft Copilot Studio, Azure AI Foundry, Amazon Bedrock AgentCore, ServiceNow, Salesforce…)

Version 1.0 introduced several breaking changes compared with 0.x (method names, state names, removed fields). If you are reading tutorials from 2025, check which version they target.

3. Key concepts

A2A relies on a small vocabulary:

Concept	Role
Client agent	The agent that initiates the request (often an orchestrator).
Remote agent (A2A server)	The agent that receives and executes the task. Roles are fluid: an agent can be the client in one interaction and the server in another.
Agent Card	The agent's public JSON identity card: name, description, version, skills, endpoints, authentication methods.
Skill	A capability declared in the Agent Card (e.g. `book_flight`), with a description, tags, examples and accepted formats.
Task	A unit of work with an identifier and a state, generated by the server. It can last a few milliseconds or several days.
Message	One turn of conversation, carried by a role (`user` or `agent`).
Part	A piece of content inside a message: text, structured JSON data, a URL to a file, or raw bytes.
Artifact	The deliverable produced by the task (a report, a JSON itinerary, a PDF…), also made of Parts.
Context	An identifier used to group several tasks and messages belonging to the same conversation.

4. A three-layer architecture

The v1.0 specification is split into three layers, so you can change transport without rewriting the agent's logic:

┌─────────────────────────────────────────────────────────┐
│ Layer 3 — Protocol bindings                             │
│   JSON-RPC 2.0 over HTTPS  │  gRPC  │  HTTP+JSON (REST) │
├─────────────────────────────────────────────────────────┤
│ Layer 2 — Abstract operations                           │
│   SendMessage, SendStreamingMessage, GetTask,           │
│   ListTasks, CancelTask, SubscribeToTask,               │
│   push notification config, Agent Card retrieval        │
├─────────────────────────────────────────────────────────┤
│ Layer 1 — Canonical data model                          │
│   AgentCard, AgentSkill, Task, Message, Part,           │
│   Artifact, Extension (Protocol Buffers + JSON Schema)  │
└─────────────────────────────────────────────────────────┘

Each agent advertises the binding(s) it supports in its Agent Card (the supportedInterfaces field). JSON-RPC is the most common for publicly exposed agents; gRPC is attractive for low-latency internal traffic.

5. How it works, step by step

Let's take a concrete scenario: an HR agent needs to organise an interview and delegates the booking to a travel agent run by another team.

![A2A task delegation sequence: discovery, authentication, sending, tracking, multi-turn exchange and result]

Step 1 — Discovery via the Agent Card

The remote agent publishes its card at a standard URL: https://<domain>/.well-known/agent-card.json (an RFC 8615 convention). A simplified, v1.0-compliant example:

{
  "name": "Travel booking agent",
  "description": "Books flights and hotels for employees.",
  "version": "1.2.0",
  "provider": {
    "organization": "MyCompany",
    "url": "https://mycompany.example"
  },
  "supportedInterfaces": [
    {
      "url": "https://travel.mycompany.example/a2a",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "extendedAgentCard": false
  },
  "defaultInputModes": ["text/plain", "application/json"],
  "defaultOutputModes": ["application/json"],
  "skills": [
    {
      "id": "book_flight",
      "name": "Book a flight",
      "description": "Books a flight given an origin, a destination and dates.",
      "tags": ["travel", "booking"],
      "examples": [
        "Book a Paris–Lyon flight on 12 November for employee 4432"
      ]
    }
  ],
  "securitySchemes": {
    "corp_oauth": {
      "type": "oauth2",
      "flows": {
        "clientCredentials": {
          "tokenUrl": "https://auth.mycompany.example/token",
          "scopes": { "flights:write": "Book flights" }
        }
      }
    }
  },
  "security": [{ "corp_oauth": ["flights:write"] }]
}

The client reads the card, checks that the book_flight skill exists, picks an interface and identifies the expected authentication method.

Discovery can also go through an internal registry (a catalogue of vetted agents) or direct configuration (a hard-coded URL) for tightly coupled systems.

Step 2 — Authentication

Credentials never travel in the body of the A2A message: they are sent in HTTP headers (Authorization: Bearer …). Here, the client runs an OAuth2 client credentials flow against the declared tokenUrl.

Step 3 — Sending the task (`SendMessage`)

POST /a2a HTTP/1.1
Host: travel.mycompany.example
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json
Accept: application/json, text/event-stream

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "SendMessage",
  "params": {
    "message": {
      "role": "ROLE_USER",
      "parts": [
        {
          "text": "Book a direct Paris–Lyon flight on 12 November for employee 4432."
        }
      ]
    },
    "configuration": { "returnImmediately": true }
  }
}

Things to note:

The client does not supply a task identifier: the server generates it and returns it.
For a trivial answer, the server can return a Message directly instead of creating a Task.
returnImmediately: true asks the server to hand back the newly created task right away, so the client can follow progress in parallel (in v1.0 the default behaviour is blocking).

Step 4 — Tracking progress

Three mechanisms, depending on duration and topology:

Mechanism	When to use it	Operations
Polling	Short tasks, simple client	`GetTask` at regular intervals
SSE streaming	The client stays connected and wants real-time updates	`SendStreamingMessage` (send + stream) or `SubscribeToTask` (subscribe to an existing task)
Push notifications	Very long tasks, disconnected client (mobile, serverless)	The client registers a webhook; the server POSTs updates to it, authenticated (signed JWT, HMAC or mTLS)

Example of a received SSE stream:

data: {"task": {"id": "task-9876", "status": {"state": "TASK_STATE_SUBMITTED"}}}

data: {"statusUpdate": {"taskId": "task-9876", "status": {"state": "TASK_STATE_WORKING"}}}

data: {"artifactUpdate": {"taskId": "task-9876", "artifact": {"artifactId": "a1", "name": "itinerary", "parts": [ ... ]}}}

data: {"statusUpdate": {"taskId": "task-9876", "status": {"state": "TASK_STATE_COMPLETED"}}}

The stream closes automatically when the task reaches a terminal state.

Step 5 — Multi-turn exchange (if needed)

If the remote agent needs clarification ("economy or business class?"), the task moves to INPUT_REQUIRED. The client replies with a new SendMessage carrying the same task identifier, and work resumes.

Step 6 — Retrieving the result

Artifacts hold the final deliverable. A client that missed the stream can always call GetTask to fetch the full task, with its history and artifacts.

Bonus: a minimal Python client

import requests

BASE = "https://travel.mycompany.example"

# 1. Discovery
card = requests.get(f"{BASE}/.well-known/agent-card.json", timeout=10).json()
if "book_flight" not in {s["id"] for s in card.get("skills", [])}:
    raise RuntimeError("The agent does not offer the book_flight skill")

endpoint = card["supportedInterfaces"][0]["url"]
headers = {"Authorization": "Bearer <token>", "Content-Type": "application/json"}

# 2. Send the task
payload = {
    "jsonrpc": "2.0",
    "id": 1,
    "method": "SendMessage",
    "params": {
        "message": {
            "role": "ROLE_USER",
            "parts": [{"text": "Book a Paris–Lyon flight on 12/11 for employee 4432."}],
        },
        "configuration": {"returnImmediately": True},
    },
}
task = requests.post(endpoint, json=payload, headers=headers, timeout=30).json()["result"]

# 3. Read the state (simple polling)
status = requests.post(
    endpoint,
    json={"jsonrpc": "2.0", "id": 2, "method": "GetTask",
          "params": {"taskId": task["task"]["id"]}},
    headers=headers, timeout=30,
).json()
print(status)

In production, prefer the official SDKs (Python, JavaScript, Java, Go, .NET) published by the A2A project over hand-written HTTP calls. The exact shape of result depends on the server's response (task or message).

6. Task lifecycle

![A2A task lifecycle: in-progress, interrupted and terminal states]

State (v1.0)	Category	Meaning
`TASK_STATE_SUBMITTED`	in progress	Accepted, not yet started
`TASK_STATE_WORKING`	in progress	Actively being processed
`TASK_STATE_INPUT_REQUIRED`	interrupted	Waiting for information from the client
`TASK_STATE_AUTH_REQUIRED`	interrupted	The client must provide additional credentials
`TASK_STATE_COMPLETED`	terminal	Finished successfully
`TASK_STATE_FAILED`	terminal	Unrecoverable error
`TASK_STATE_CANCELED`	terminal	Cancelled (often via `CancelTask`)
`TASK_STATE_REJECTED`	terminal	Refused by the agent (policy, quota, capability)

7. Security

A2A builds on web standards rather than inventing its own:

Encrypted transport: HTTPS (TLS 1.2 minimum) is mandatory in production.
Authentication schemes aligned with OpenAPI: OAuth 2.0, OpenID Connect, API key, mTLS. Declared in securitySchemes and required via security.
Signed Agent Cards: a JWS signature (RFC 7515) computed over a canonical form of the card (RFC 8785) makes any tampering detectable. Otherwise, a modified card could redirect calls or inject malicious content into the client agent's prompt.
Extended Agent Card: an agent can expose a minimal public card and a more detailed one, available only after authentication.
Traceability: the specification recommends OpenTelemetry and propagating W3C Trace Context headers (traceparent) to follow a request across the whole chain of agents.

For high assurance: combine mTLS and OAuth2, or use sender-constrained tokens (DPoP, RFC 9449), so that a stolen token is useless from another machine.

8. A2A vs MCP

Reminder: what is MCP?

MCP (Model Context Protocol), launched by Anthropic in late 2024 and now widely adopted, standardises the connection between an AI application (the client/host) and servers that expose tools, resources (data) and prompts. It runs on JSON-RPC 2.0, locally over stdio or remotely over HTTP. Its specifications are named by date; the 2026-07-28 revision notably made the protocol stateless (sessions and the initialisation handshake were removed), which makes horizontal scaling of servers easier.

Comparison table

Criterion	A2A	MCP
Purpose	Make autonomous agents collaborate	Give an agent access to tools and data
Analogy	A colleague you delegate a file to	A toolbox you use yourself
Nature of the counterpart	Opaque, autonomous, reasons on its own	A deterministic function or exposed data source
Unit of exchange	A task (`Task`) with a state and a lifecycle	A tool call / resource read
Typical duration	Seconds to days, multi-turn	Usually short, request/response
Interaction	Negotiation possible (`INPUT_REQUIRED`, `AUTH_REQUIRED`)	The model calls, the tool answers
Discovery	Public Agent Card (`/.well-known/agent-card.json`), registries	Listing tools/resources on the connected server
Transports	JSON-RPC 2.0, gRPC, HTTP+JSON	JSON-RPC 2.0 over stdio or HTTP
Async / long-running	Native: SSE, webhook push notifications	Possible but less central
Content	Multimodal via Parts (text, JSON, files, bytes)	Structured results, text, images, resources
Topology	Peer-to-peer, interchangeable client/server roles	Host → client → server
Origin / governance	Google → Linux Foundation	Anthropic → open governance by the MCP community
Maturity (Oct. 2026)	v1.0 stable (March 2026)	2026-07-28 revision stable

The right question to ask

"Do I want to perform a precise action, or hand over a goal to someone who will figure out how to reach it?"

A precise, deterministic action (an SQL query, reading a file, calling a weather API) → MCP.
A goal to reach by a system that reasons, can ask questions, and whose implementation you don't want to know about → A2A.

There is a grey area: you can expose a whole agent as an MCP "tool". That works for simple cases, but you lose what makes A2A strong: state tracking, multi-turn exchanges, long-running tasks and cross-organisation discovery.

9. Using A2A and MCP together

The two protocols are complementary and together form the communication stack of multi-agent systems:

Scenario:

The user asks the orchestrator: "Organise Marie's interview in Lyon on Thursday."
The orchestrator delegates via A2A to the HR agent ("schedule the interview") and to the travel agent ("book the trip").
Each of these agents uses MCP internally to query its own tools: calendar, HRIS, booking API.
The agents return their artifacts (confirmed slot, ticket) to the orchestrator via A2A.

Rule of thumb: A2A between agents, MCP between an agent and its tools.

10. Current limitations and best practices

Limitations to be aware of:

Per-skill data schema: a skill declares that it accepts application/json, but the specification does not standardise the exact schema expected. Workaround: publish a JSON Schema in the skill description or through an Extension declared in the Agent Card.
Downscoping across delegation chains: A2A says how to pass credentials, not how to narrow them when a highly privileged orchestrator delegates to a less privileged agent. Workaround: OAuth 2.0 Token Exchange (RFC 8693) to issue short-lived, narrowly scoped tokens.
No standard registry: discovery through a central catalogue is still something you build yourself.
Migrating from 0.x to 1.0: method names (message/send → SendMessage), prefixed state names, removal of the kind and final fields.

Best practices:

Treat the Agent Card as a contract: any change to a skill, URL or capability must bump the version.
Sign Agent Cards and verify signatures on the client side.
Serve the card with Content-Type: application/json.
Put an API gateway in front of agents to centralise authentication, quotas, logging and long-lived connection handling.
Instrument with OpenTelemetry from day one: debugging a chain of five agents without distributed traces is painful.
Never blindly trust content received from another agent: it is data, not instructions (prompt-injection risk).

11. Conclusion

A2A does for agents what HTTP did for documents or SMTP for email: it provides a common, neutral language that lets heterogeneous systems cooperate without bespoke integration. With a stable v1.0, Linux Foundation governance and adoption by the major platforms, it is now ready for production use.

MCP and A2A are not competitors: MCP gives an agent hands; A2A gives it colleagues. A modern multi-agent architecture uses both.

Authentication protocols for applications: REST APIs, MCP servers and beyond

Marwa Sahli — Thu, 05 Nov 2026 08:28:32 +0000

Introduction

There is no single ideal authentication protocol, only the right protocol for each situation: who is calling (a human, a service, an AI agent), on whose behalf, and at what level of risk. An API key is enough for an internal script; a consumer application requires OAuth 2.0 and OpenID Connect; a remote MCP server now follows a precise OAuth 2.1 profile.

Two notions are often confused:

Authentication (AuthN): proving who you are (a user, an application, a machine).
Authorization (AuthZ): determining what you are allowed to do (read, write, administer).

OAuth 2.0 is a delegated authorization protocol; OpenID Connect adds the authentication layer on top. That distinction explains why the two are almost always used together.

This article reviews the methods, from the simplest to the most robust, then looks in detail at MCP (Model Context Protocol) servers, which connect AI agents to tools and data.

Simple methods: Basic Auth and API keys

Both methods rely on a static secret sent with every request. They are easy to implement and suit internal or server-to-server exchanges, but never an application acting on behalf of third-party users.

HTTP Basic Authentication

The client sends the username and password, Base64-encoded, in the Authorization header:

GET /api/orders HTTP/1.1
Authorization: Basic YWxpY2U6czNjcjN0

Pros: standard (RFC 7617), supported everywhere, no infrastructure.
Limits: Base64 is not encryption, so HTTPS is mandatory; the password travels with every call; no expiry, no scope, revocation = changing the password.
Reasonable use: internal tools, admin endpoints behind a VPN, the initial exchange to obtain a token.

API keys

A long random string identifies the calling application, sent in a dedicated header:

GET /v1/weather?city=Lyon HTTP/1.1
X-API-Key: sk_live_4f9a…

Pros: easy to issue, revoke and rotate; ideal for per-customer billing and quotas.
Limits: the key identifies an application, not a user; it is a "bearer" secret (whoever holds it can use it); often no expiry and no fine-grained scope.
Best practices: send it in a header, never in the URL (it would end up in logs); store only a hash on the server side; prefix keys (sk_live_, sk_test_) to make leaks easier to detect; allow several active keys so they can be rotated without downtime.

Tokens: sessions, Bearer and JWT

Instead of sending a permanent secret, the client exchanges proof of identity for a short-lived token. This is the basis of every modern method.

Sessions and cookies

After login, the server creates a session and returns its identifier in a cookie. This is the historical model for server-rendered web applications.

Strengths: immediate revocation (delete the session); HttpOnly, Secure and SameSite cookies protect against theft by JavaScript.
Limits: server-side state (shared storage needed across instances), CSRF protection required, poorly suited to mobile clients or APIs consumed by third parties.

Bearer tokens

A bearer token (RFC 6750) is sent in the Authorization: Bearer <token> header. Whoever holds it can use it, so it must be short-lived, sent over HTTPS and never logged. The token can be opaque (a string the server checks with the issuer through introspection, RFC 7662) or self-contained (a JWT).

JSON Web Token (JWT)

A JWT (RFC 7519) is made of three Base64URL-encoded parts: header.payload.signature. The payload contains claims:

{
  "iss": "https://auth.example.com",
  "sub": "user_8241",
  "aud": "https://api.example.com",
  "exp": 1793011200,
  "scope": "orders:read"
}

The API verifies the signature with the issuer's public key (published as a JWKS), then checks iss, aud and exp, with no network call.

Strengths: fast local verification, ideal for microservices.
Pitfalls: a JWT cannot be revoked before it expires (hence short lifetimes, 5 to 15 minutes, plus refresh tokens); reject the none algorithm and pin the list of accepted algorithms (RS256, ES256…); the payload is readable by anyone, it is not encrypted; never forget to check the aud audience.

A JWT is a token format, not a protocol: how you obtain that token is what OAuth 2.0 defines.

OAuth 2.0 and OAuth 2.1: delegated authorization

OAuth 2.0 (RFC 6749) lets an application access an API on behalf of a user, without ever knowing their password. It is the de facto standard for public APIs (Google, GitHub, Microsoft, Salesforce…). OAuth 2.1, being finalised at the IETF, consolidates a decade of best practice: PKCE becomes mandatory, and the implicit and "password" flows are removed.

The four roles

Role	Description	Example
Resource owner	The user who gives consent	Alice
Client	The application requesting access	A mobile app, an MCP client
Authorization server	Authenticates and issues tokens	Keycloak, Auth0, Entra ID, Okta
Resource server	The protected API that validates tokens	The REST API, the MCP server

The recommended flow: Authorization Code + PKCE

The client generates a random secret (code_verifier) and its SHA-256 hash (code_challenge).
It redirects the user to the authorization server with client_id, redirect_uri, scope, state and code_challenge.
The user authenticates and gives consent.
The authorization server redirects back to the client with a single-use authorization code.
The client exchanges this code, together with the code_verifier, for an access token (and often a refresh token).
The client calls the API with Authorization: Bearer <access_token>.

PKCE (RFC 7636) prevents an attacker who intercepts the code from exchanging it, since they don't know the code_verifier. It is now required for every client, including server-side applications.

Other flows (grant types)

Flow	Use case	User present?
Authorization Code + PKCE	Web apps, mobile apps, SPAs, MCP clients	Yes
Client Credentials	Service to service, scheduled jobs, back ends	No
Device Authorization (RFC 8628)	TVs, CLIs, connected devices without a browser	Yes, on another device
Refresh Token	Renew an expired access token without logging in again	No
Token Exchange (RFC 8693)	A service swaps a token it received for a token for a downstream API	No
~~Implicit~~, ~~Password~~	Removed in OAuth 2.1	—

Scopes, audiences and refresh tokens

Scopes (orders:read, profile) limit what the token allows; request the bare minimum.
The resource parameter (RFC 8707) binds the token to a specific API: a token issued for API A must be rejected by API B.
Refresh tokens must be rotated for public clients (each use issues a new one and invalidates the old one).

OpenID Connect and SAML: federated identity and SSO

When the application needs to know who the user is (single sign-on, "Sign in with Google"), you add an identity layer on top of OAuth: OpenID Connect for modern applications, SAML for existing enterprise systems.

OpenID Connect (OIDC)

OIDC reuses OAuth 2.0's Authorization Code flow and adds the openid scope. The authorization server (called the OpenID Provider) returns, in addition to the access token, an ID token: a signed JWT describing the user (sub, email, name, auth_time…).

Automatic discovery: /.well-known/openid-configuration publishes the endpoints, the algorithms and the public key (JWKS).
UserInfo endpoint to obtain additional attributes.
Golden rule: the ID token is for the client to learn who the user is; the access token is for calling the API. Never send an ID token to an API as an access token.

SAML 2.0

SAML (Security Assertion Markup Language) exchanges signed XML assertions between an identity provider (IdP: ADFS, Okta, Entra ID) and a service provider (SP), through browser redirects.

Strengths: very widespread in large enterprises and B2B SaaS, mature.
Limits: verbose, hard to implement correctly (XML signature wrapping attacks), designed for the browser rather than for APIs or mobile apps.
Trend: new projects favour OIDC; SAML is still needed to integrate with existing corporate directories, often through an identity broker (Keycloak, Auth0) that translates SAML into OIDC.

What about the users themselves?

OIDC and SAML delegate identity verification to the identity provider, which can then use multi-factor authentication (MFA) or passkeys (WebAuthn/FIDO2), today the most phishing-resistant method.

mTLS, HMAC signatures and DPoP: strong authentication between machines

These mechanisms address the main weakness of bearer tokens (a stolen token can be used by anyone) by requiring proof of possession of a key that only the legitimate client holds.

Mutual TLS (mTLS)

In a classic TLS handshake, only the server presents a certificate. With mTLS, the client presents one too, signed by a certificate authority the server trusts.

Uses: microservice communication (often automated by a service mesh such as Istio or Linkerd), banking APIs and Open Banking, zero-trust architectures.
With OAuth: RFC 8705 binds an access token to the client's certificate (a certificate-bound token); a stolen token is useless without the private key.
Constraints: certificate lifecycle management (issuance, rotation, revocation); harder to deploy in browsers or on mobile.

Request signing (HMAC)

The client and the server share a secret key. The client computes a signature (HMAC-SHA256) over parts of the request (method, path, timestamp, body hash) and sends it in a header. The server recomputes it and compares.

Examples: AWS Signature Version 4, webhook verification (Stripe, GitHub, Slack).
Strengths: the secret never travels; message integrity is guaranteed; the timestamp blocks replay.
Standardisation: RFC 9421 (HTTP Message Signatures) now standardises this approach, including with asymmetric keys.

DPoP (Demonstrating Proof of Possession)

DPoP (RFC 9449) brings proof of possession to the application layer, without a certificate infrastructure. The client generates a key pair and attaches a small signed JWT (the DPoP header) to every request, covering the method, the URL and a timestamp. The authorization server binds the access token to that public key.

DPoP is a good fit for SPAs and mobile apps, where mTLS is hard to deploy.

The case of MCP servers

A remote MCP server is an OAuth 2.1 resource server: under the 2026-07-28 revision of the specification, the client discovers the authorization server on its own, identifies itself with a URL (Client ID Metadata Document) and obtains a token valid for that server only. A local (stdio) MCP server, on the other hand, simply reads its credentials from the environment.

Reminder: what is MCP?

The Model Context Protocol is an open protocol that connects AI applications (Claude, ChatGPT, VS Code, Cursor…) to tools and data sources through "MCP servers". What makes it special from a security standpoint: an agent can connect to a server it has never seen before, with no prior relationship between the client's vendor and the server's. The authentication profile is designed for exactly that scenario.

Two transports, two approaches

The specification makes authorization optional, but sets out what to do depending on the transport.

Transport	Where the server runs	Authentication
stdio	Local process launched by the host application	Do not follow the OAuth specification; read credentials from the environment (variables, config files)
Streamable HTTP	Remote server reachable by URL	The MCP specification's OAuth 2.1 profile

The old HTTP+SSE transport (2024-11-05 revision) is deprecated.

The authorization flow, step by step

The client only needs the MCP server's URL: an initial 401 rejection tells it where to find the metadata; it then runs a standard Authorization Code + PKCE flow and replays its request with the token.

The server's 401 response looks like this:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

The standard building blocks involved

Building block	Reference	Role in MCP	Requirement
Protected Resource Metadata	RFC 9728	The MCP server states which authorization server to use	Mandatory (server and client)
Authorization server metadata	RFC 8414 and OpenID Connect Discovery	Endpoint discovery	The client must support both
PKCE	RFC 7636	Protects the code exchange	Mandatory
Resource Indicators	RFC 8707	Binds the token to the target MCP server	Mandatory
Client ID Metadata Documents (CIMD)	IETF draft	The `client_id` is an HTTPS URL pointing to a JSON document describing the client	Recommended
Dynamic Client Registration	RFC 7591	Automatic client registration	Optional, deprecated in 2026-07-28
Issuer validation	RFC 9207	The client checks `iss` before exchanging the code	Mandatory since 2026-07-28

Client registration: the order of precedence

How does an MCP client obtain a client_id from an authorization server it doesn't know? The specification recommends this order:

Use pre-registered credentials for that server, if it has any.
Use a Client ID Metadata Document if the authorization server advertises client_id_metadata_document_supported.
Fall back to Dynamic Client Registration if the server exposes a registration_endpoint.
Otherwise, ask the user to enter the client details themselves.

CIMD has the advantage of being portable: the identifier is a URL hosted by the client's vendor, resolved on demand by any authorization server, with no registration database to maintain.

{
  "client_id": "https://app.example.com/oauth/client-metadata.json",
  "client_name": "My MCP client",
  "redirect_uris": ["http://127.0.0.1:3000/callback"],
  "grant_types": ["authorization_code"],
  "token_endpoint_auth_method": "none"
}

MCP-specific security points

No token passthrough: the MCP server must never forward the token it received from the client to a downstream API; it obtains its own token (for example via Token Exchange).
Audience validation: the MCP server only accepts tokens issued specifically for it.
Issuer-bound credentials: a client must associate its credentials with the authorization server that issued them and never reuse them with another one.
Incremental consent: since the 2025-11-25 revision, a client can request additional scopes at the moment a tool needs them, rather than asking for everything up front.
stdio servers: secrets in the environment should have minimal scope, because the local process runs with the user's permissions.

Comparison and decision guide

The right choice depends first on whether a human user is involved, then on the level of risk.

Method	Identifies	Expiry / revocation	Complexity	Typical use case
Basic Auth	A user or a technical account	None / password change	Very low	Internal tools, administration
API key	An application	Manual / simple revocation	Low	Public APIs with quotas, server integrations
Session + cookie	A user	Configurable / immediate	Low	Classic web applications
JWT	User or application	Short / hard before expiry	Medium	Microservices, stateless APIs
OAuth 2.0 / 2.1	An application acting for a user	Short + refresh / via the authorization server	Medium to high	APIs open to third parties, remote MCP clients
OpenID Connect	A user (identity)	Short	Medium	SSO, "Sign in with…"
SAML 2.0	A user (identity)	Short	High	Legacy enterprise SSO
mTLS	A machine	Certificate lifetime / CRL, OCSP	High	Zero trust, service mesh, finance
HMAC signature	An application + message integrity	Per request (timestamp)	Medium	Webhooks, cloud APIs
DPoP	Application, token bound to a key	Short	Medium	High-security SPAs and mobile apps

Decision shortcut:

A user signs in to your application → OIDC (with passkeys or MFA at the identity provider).
A third-party application accesses a user's data → OAuth 2.1 Authorization Code + PKCE.
A service calls another service → Client Credentials, hardened with mTLS or DPoP if the data is sensitive.
You receive webhooks → HMAC signature.
An internal script or a prototype → API key, with rotation.
A remote MCP server → the MCP specification's OAuth 2.1 profile (previous section); a local MCP server → environment variables.

Best practices and conclusion

Whatever protocol you pick, most incidents come from implementation details rather than from the protocol itself.

HTTPS everywhere, no exceptions, including internally.
Don't reinvent: rely on a proven authorization server (Keycloak, Auth0, Entra ID, Okta, Cognito…) and maintained libraries.
Short-lived tokens (minutes) and rotated refresh tokens.
Validate every token: signature, issuer iss, audience aud, expiry exp, scopes.
Least privilege: minimal scopes, one token per target API.
Secrets out of the code: a vault (Vault, AWS Secrets Manager…) or environment variables, never in Git.
Nothing sensitive in URLs or logs (keys, tokens, authorization codes).
Rate limiting on authentication endpoints to slow down credential stuffing.
Log and monitor token issuance, failures and revocations.
For AI agents: explicit user consent, tokens limited to the target MCP server, no token passthrough to downstream APIs.

In short, API keys and Basic Auth remain useful for simple cases; OAuth 2.1 and OpenID Connect are the norm as soon as users and third parties are involved; mTLS, HMAC and DPoP harden machine-to-machine exchanges. MCP servers reinvent nothing: they apply these standards through a strict profile, designed so that AI agents can connect to thousands of services without prior registration.

Sources

MCP — Authorization, 2026-07-28 revision
MCP — Client Registration
MCP Authorization Spec 2026-07-28: what changed (SSOJet)
MCP Authentication: requirements of the 2026-07-28 revision (SSOJet)
What's new in the MCP 2025-11-25 authorization spec (den.dev)
RFCs cited: 6749 (OAuth 2.0), 6750 (Bearer), 7519 (JWT), 7617 (Basic), 7636 (PKCE), 7662 (introspection), 8414, 8628, 8693, 8705, 8707, 9207, 9421, 9449, 9728 — available at rfc-editor.org

Originally published on my blog. Une version française est disponible ici.

DEV Community: Marwa Sahli

The A2A protocol: how it works, step by step, and how it compares with MCP

Contents

1. What is A2A?

2. History and governance

3. Key concepts

4. A three-layer architecture

5. How it works, step by step

Step 1 — Discovery via the Agent Card

Step 2 — Authentication

Step 3 — Sending the task (SendMessage)

Step 4 — Tracking progress

Step 5 — Multi-turn exchange (if needed)

Step 6 — Retrieving the result

Bonus: a minimal Python client

6. Task lifecycle

7. Security

8. A2A vs MCP

Reminder: what is MCP?

Comparison table

The right question to ask

9. Using A2A and MCP together

10. Current limitations and best practices

11. Conclusion

Further reading

Authentication protocols for applications: REST APIs, MCP servers and beyond

Introduction

Simple methods: Basic Auth and API keys

HTTP Basic Authentication

API keys

Tokens: sessions, Bearer and JWT

Sessions and cookies

Bearer tokens

JSON Web Token (JWT)

OAuth 2.0 and OAuth 2.1: delegated authorization

The four roles

The recommended flow: Authorization Code + PKCE

Other flows (grant types)

Scopes, audiences and refresh tokens

OpenID Connect and SAML: federated identity and SSO

OpenID Connect (OIDC)

SAML 2.0

What about the users themselves?

mTLS, HMAC signatures and DPoP: strong authentication between machines

Mutual TLS (mTLS)

Request signing (HMAC)

DPoP (Demonstrating Proof of Possession)

The case of MCP servers

Reminder: what is MCP?

Two transports, two approaches

The authorization flow, step by step

The standard building blocks involved

Client registration: the order of precedence

MCP-specific security points

Comparison and decision guide

Best practices and conclusion

Sources

Step 3 — Sending the task (`SendMessage`)