Authentication

The Atlassian A2A Gateway uses the OAuth 2.0 authorization code flow for all authenticated requests. PKCE with the S256 method is required - authorization requests without a code_challenge are rejected. Unlike the MCP Server, which also supports API tokens, A2A is OAuth-only - there is no API token or session-based fallback.

Your agent platform must register with Atlassian through Dynamic Client Registration (DCR). Manual OAuth client creation is not supported.

How it works

1. The external agent fetches the Agent Card from https://a2a.atlassian.com/.well-known/agent.json.
2. The card's securitySchemes section describes the OAuth 2.0 authorization code flow, including the required scopes and the Atlassian authorization endpoints. All authorization requests must include a PKCE code_challenge using the S256 method.
3. The agent registers itself with Atlassian through DCR to obtain a client_id.
4. The user is redirected to the Atlassian authorization URL to grant consent.
5. The authorization code is exchanged for an access token and refresh token.
6. The agent includes the access token in the Authorization: Bearer <token> header when calling https://a2a.atlassian.com/v1/rovo.
7. The refresh token is used to obtain new access tokens when the current one expires.

OAuth scopes

A2A requires a minimal set of scopes:

These scopes are listed in the Agent Card's securitySchemes section and in the security field.

Organization enablement

Valid OAuth credentials are necessary, but they are not sufficient on their own. A2A task execution is disabled by default until an organization administrator enables A2A for the organization.

• The Agent Card at /.well-known/agent.json remains public so agents can always discover the gateway.
• The JSON-RPC endpoint at /v1/rovo returns 403 with error code -32008 when the organization cannot be resolved from the access token.
• It returns 403 with error code -32007 when the organization resolves but A2A is not enabled for it.

The gateway resolves the organization before it checks the admin setting, so the two errors are mutually exclusive. Receiving -32007 confirms your organization was identified.

If you can authenticate successfully but still cannot send requests, this is the first setting to check.

Supported authentication patterns

The gateway supports one OAuth setup pattern: Dynamic Client Registration (DCR). Your agent platform registers itself with Atlassian automatically and usually needs nothing from you beyond the Agent Card URL or the gateway URL.

If your agent platform instead asks you for a client ID and client secret, see Manual client registration is not supported.

Dynamic Client Registration (DCR)

If the external agent supports DCR, the authentication flow can be mostly automated:

1. The agent reads the securitySchemes from the Agent Card.
2. The agent registers itself with the Atlassian authorization server using OAuth 2.0 Dynamic Client Registration.
3. The agent receives a client_id and client_secret.
4. The authorization code flow proceeds from there. The agent must generate a PKCE verifier and send code_challenge and code_challenge_method=S256 on the authorization request, then send code_verifier on the token exchange.

The current production Agent Card advertises these OAuth endpoints:

• Authorization URL: https://auth.atlassian.com/authorize
• Token URL: https://auth.atlassian.com/oauth/token

The Agent Card's securitySchemes section is the primary way to discover the authorization and token URLs.

Manual client registration is not supported

Dynamic Client Registration is required. The full_access:chat:rovo scope cannot be added to an app created in the Atlassian Developer Console, so manual client registration is not supported.

Gateway OAuth values

These values are set by the gateway and can be read from the live Agent Card's securitySchemes field (see Agent Card schema):

Always read these values from the Agent Card rather than hardcoding them, so your client keeps working if they change.

Ensure your Atlassian admin has enabled A2A for your organization before testing requests.

Refreshing access tokens

Access tokens are short-lived. The token response includes an expires_in value in seconds. Refresh the token before it expires rather than sending the user through consent again.

Request the offline_access scope during authorization so that the token response includes a refresh_token. To exchange it, POST to the token URL from the Agent Card:

1
2
curl --request POST 'https://auth.atlassian.com/oauth/token' \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'grant_type=refresh_token' \
  --data-urlencode 'client_id=<CLIENT_ID>' \
  --data-urlencode 'refresh_token=<REFRESH_TOKEN>'

Clients registered through DCR with token_endpoint_auth_method set to none send client_id and no client secret, as shown above. If your client registered with a client secret, include client_secret as well.

Permission model

All task executions respect the authenticated user's Atlassian permissions:

• Jira — Respects project roles, issue security levels, and permission schemes.
• Confluence — Respects space permissions, page restrictions, and content security.
• Rovo — Access is scoped to what the user can see across their Atlassian products.

The gateway never escalates privileges. If a user cannot access a resource in the Atlassian UI, Rovo will not access it via A2A either.

Revoking access

• Users can revoke their authorization from Atlassian profile settings.
• Admins can disable A2A for the organization and can review third-party app access in Atlassian Administration.

Next steps

• Getting started — Connect your first agent.
• Admin controls — Review the organization-level enablement required for task execution.
• Architecture — Review the Agent Card fields and request flow.
• Troubleshooting — Common authentication issues and solutions.