a2a cloud
sign in

Log in to a2a cloud — every way to authenticate.

Sign in to the dashboard at app.a2acloud.io, or authenticate from the CLI with `a2a login`. One identity — backed by a dedicated Keycloak realm — works across the dashboard, the API, MCP servers, and agent-to-agent calls, with passkeys, scoped tokens, and signed grants instead of shared passwords.

one identity · people, CLIs, agents, and tools

0
auth surfaces
0
shared passwords
0
access token (min)
the problem

One login for people, agents, and the tools they call.

Agent platforms accumulate logins: a dashboard password for humans, a personal access token in the CLI, a static API key for programmatic calls, another key for the MCP server, and shared credentials whenever one agent calls another. Each is a separate secret to leak, rotate, and audit. a2a cloud puts every one of those surfaces behind a single identity system with short-lived, scoped tokens.

Humans reuse dashboard passwords; most static API keys never expire.
Shared credentials mean an agent inherits the caller's full authority.
MCP tools are often gated by one key checked once, not per call.
Every long-lived secret is one more thing to leak, rotate, and prove.
the a2a way

Sign in once — the same identity everywhere.

Dashboard, CLI, API, MCP, and agent-to-agent calls all resolve to one Keycloak-backed identity, narrowed by scopes and grants at every hop.

Dashboard loginPasswordless & passkeysCLI loginToken paste for CIAPI bearer tokensOAuth scopesMCP server authPer-agent auth modelsAgent-to-agent grants

Dashboard login

Sign in at app.a2acloud.io. Identity is backed by a dedicated Keycloak realm — email and password with a strong policy (12+ chars, mixed case, digit, symbol) and verified email.

Passwordless & passkeys

WebAuthn is enabled, including passwordless mode. Sign in with a passkey, security key, or platform biometric instead of a password.

CLI login

`a2a login` opens a browser OAuth flow (Authorization Code + PKCE), captures the token on a local callback, and caches it in ~/.a2a/credentials.json. `a2a whoami` and `a2a logout` round it out.

Token paste for CI

No browser? `a2a login --token <jwt>` uses a pre-issued Keycloak token directly — the path for CI, containers, and headless machines.

API bearer tokens

The API and MCP endpoints accept a Keycloak RS256 JWT as a bearer token — signature verified via JWKS, with issuer, expiry, and subject checks. Access tokens are short-lived; the CLI refreshes them automatically.

OAuth scopes

Tokens carry least-privilege scopes: openid, email, offline_access, plus agent:read and mcp:invoke. The surface an agent can touch is bounded by the scope it was granted.

MCP server auth

Every hosted MCP server validates a Keycloak JWT and enforces scopes per method: tools/list needs agent:read, tools/call needs mcp:invoke. Optional resource-audience binding blocks token replay.

Per-agent auth models

Each agent declares how callers authenticate: NoAuth (public), APIKeyAuth, JWTAuth, PlatformUserAuth, or a remote bearer / OIDC-userinfo resolver that bridges an external IdP or SAML-backed service.

Agent-to-agent grants

When an agent calls another, the platform mints an Ed25519-signed grant — audience, TTL, file and tool scope — verified without a registry round-trip. No shared credentials cross the boundary.

side-by-side

Credential sprawl vs. one scoped identity.

dimension
the usual
a2a cloud
people
Shared passwords in a vault, no second factor, one login reused across everything.
Keycloak login with a strong password policy and WebAuthn passkeys — passwordless if you want it.
CLI / CI
A long-lived personal access token pasted into a dotfile and forgotten.
`a2a login` OAuth with PKCE and auto-refresh; `--token` for headless CI.
API calls
A static API key that never expires and grants everything.
Short-lived Keycloak JWT scoped to exactly what the caller needs.
MCP clients
One key that unlocks every tool, checked once at connect time.
Per-method scope enforcement — agent:read to list, mcp:invoke to call.
agent-to-agent
Agents share the caller's credentials and inherit its full authority.
Ed25519-signed grants: audience-bound, time-limited, scope-constrained.
enterprise
A homegrown SSO bridge bolted on per integration.
Bridge an external IdP or SAML-backed service through a remote-bearer / OIDC resolver.
questions

Frequently asked.

Where do I log in to a2a cloud?

Sign in to the dashboard at https://app.a2acloud.io. Authentication is handled by a dedicated Keycloak realm (auth.a2acloud.io), so the same identity works across the dashboard, the API, the CLI, and MCP endpoints.

How do I log in from the a2a CLI?

Run `a2a login`. It opens your browser to complete an OAuth Authorization Code flow with PKCE, receives the token on a local callback, and caches it in ~/.a2a/credentials.json. Use `a2a whoami` to check who you're signed in as and `a2a logout` to clear the session. For headless environments, `a2a login --token <jwt>` skips the browser.

Does a2a cloud support passwordless login or passkeys?

Yes. WebAuthn is enabled, including passwordless mode, so you can sign in with a passkey, hardware security key, or platform biometric instead of a password.

Can I sign in with Google or GitHub?

Not today — a2a cloud login uses email and password or WebAuthn passkeys. For organization-wide single sign-on, see the Enterprise plan, and note that individual agents can accept identity from an external IdP or SAML-backed service through a remote-bearer / OIDC resolver.

How do callers authenticate to a deployed agent?

Each agent declares an auth model: NoAuth for public agents, APIKeyAuth for a static bearer secret, JWTAuth or PlatformUserAuth for signed-in user identity, or a remote-bearer / OIDC-userinfo resolver that validates tokens from an external identity provider.

How do I authenticate an MCP client like Claude or Cursor?

The hosted MCP server accepts a Keycloak JWT as a bearer token and enforces scopes per method — agent:read to list tools, mcp:invoke to call them. Paste the endpoint and token into your MCP client. See the guide on connecting an agent to Claude and Cursor.

How do agents authenticate to each other?

The platform mints an Ed25519-signed grant for each agent-to-agent call, binding the audience, a short TTL, and file and tool scope. The receiving agent verifies the signature locally — no shared API keys ever cross the boundary.

sign in

One identity. Every surface.

Sign in at app.a2acloud.io, authenticate the CLI with `a2a login`, and call the API, MCP servers, and other agents with the same identity — narrowed by scopes and Ed25519 grants at every hop. No shared passwords, no long-lived keys, a signed receipt for every run.