Configuring authentication via API token

← Back to the getting started guide

Authentication via API token lets MCP clients authenticate without an interactive OAuth consent screen. Instead of redirecting a user to a browser, the client sends credentials directly in the Authorization header. For interactive, user‑driven scenarios, see Configuring OAuth 2.1.

Supported mechanisms:

Personal API tokens using Basic auth:
Authorization: Basic <base64(email:api_token)>
Service account API keys using Bearer tokens:
Authorization: Bearer <api_key>

See this page for more information on supported tools across Atlassian apps.

Personal API token (Basic auth)

Use this option when you want to authenticate MCP using a personal API token created by a user.

Step 1. Create a personal API token

Create a personal API token with the required scopes.
If necessary, you can select the scopes you want to your API token to have by clicking the Back button and manually selecting the scopes.
Note the email address of the user who owns the token.

Step 2. Base64‑encode the credentials

Create a base64‑encoded string in the format email:api_token:

# Format: email:api_token
echo -n "your.email@example.com:YOUR_API_TOKEN_HERE" | base64

This produces a base64‑encoded string representing email:api_token.

Step 3. Configure your MCP client

Add the following configuration to your MCP client’s mcp.json:

{
  "mcpServers": {
    "atlassian-rovo-mcp": {
      "url": "https://mcp.atlassian.com/v1/mcp",
      "headers": {
        "Authorization": "Basic BASE64_ENCODED_EMAIL_AND_TOKEN"
      }
    }
  }
}

Replace BASE64_ENCODED_EMAIL_AND_TOKEN with the value from Step 2.

Service account API key (Bearer token)

Use this option when you want to authenticate MCP using a service account API key managed by an admin.

Step 1. Obtain a service account API key

Ask your Atlassian admin to create a service account and generate an API key with the required scopes.
Store the API key securely (for example, in your CI/CD secret store or secrets manager).

Step 2. Configure your MCP client

Add the following configuration to your MCP client’s mcp.json:

{
  "mcpServers": {
    "atlassian-rovo-mcp": {
      "url": "https://mcp.atlassian.com/v1/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY_HERE"
      }
    }
  }
}

Replace YOUR_API_KEY_HERE with your service account API key.

Limitations

Limited tool availability	Some MCP tools may not be available when you use authentication via API token. Certain tools (for example, some Compass tools) are disabled because the required product scopes are not currently available when creating personal API tokens or API keys. As a result, the set of tools you see with this authentication method may be smaller than with OAuth. Authentication via API token is supported for additional Atlassian apps, such as Jira Service Management; tool availability still depends on the scopes granted to your token or API key.
No bounded cloud ID	OAuth tokens are typically consented for a specific `cloudId`. Tokens are not bound to a specific `cloudId`. Clients and tools must explicitly pass the `cloudId` where needed. This enables cross‑site workflows, but you must ensure you are operating on the correct `cloudId` in your requests.
No domain allowlist validation	Authentication via API token does not use an OAuth redirect URI, so redirect‑based domain allowlist checks cannot be performed. Unlike OAuth 2.1 flows, tools using API tokens are not restricted by domain allowlists and are instead governed only by your IP allowlist configuration.

Limited tool availability

Some MCP tools may not be available when you use authentication via API token.

Certain tools (for example, some Compass tools) are disabled because the required product scopes are not currently available when creating personal API tokens or API keys. As a result, the set of tools you see with this authentication method may be smaller than with OAuth.

Authentication via API token is supported for additional Atlassian apps, such as Jira Service Management; tool availability still depends on the scopes granted to your token or API key.

No bounded cloud ID

OAuth tokens are typically consented for a specific cloudId.

Tokens are not bound to a specific cloudId. Clients and tools must explicitly pass the cloudId where needed. This enables cross‑site workflows, but you must ensure you are operating on the correct cloudId in your requests.

No domain allowlist validation

Authentication via API token does not use an OAuth redirect URI, so redirect‑based domain allowlist checks cannot be performed. Unlike OAuth 2.1 flows, tools using API tokens are not restricted by domain allowlists and are instead governed only by your IP allowlist configuration.

Need help? Contact Atlassian Support or visit the getting started guide.

Was this helpful?

It wasn't accurateIt wasn't clearIt wasn't relevant

Still need help?

The Atlassian Community is here for you.

Ask the Community