Announcing authentication via API token for Atlassian Rovo MCP Server

[#1]

Atlassian's Model Context Protocol (MCP) makes it easier to bring Atlassian data and actions into AI tools through a consistent, server-side integration model. Until now, Atlassian Rovo MCP has supported only OAuth as its primary authentication mechanism, which means:

• An interactive browser-based consent flow is required, and
• MCP servers primarily run in user-interactive contexts, for example, where a human can click through OAuth prompts).

We're excited to share that authentication via API token access for Atlassian MCP is now supported — a new way to connect to MCP without an interactive consent screen, designed specifically for machine‑to‑machine and automated use cases.

What is authentication via API token access?

Authentication via API token access lets MCP clients authenticate without an interactive user flow in a browser. Instead of redirecting to a consent page, your MCP client authenticates using personal API tokens via Basic Auth, and service account–style credentials for non-human workloads.

In practice, this enables you to:

• Run MCP clients from CI/CD pipelines, scheduled jobs, or backend services
• Use MCP in non‑interactive environments (servers, cron jobs, agents, platform workers)
• Avoid browser‑based redirects while still leveraging Atlassian's existing authentication and authorization model

Authentication via API token access is an additional authentication option alongside OAuth and does not replace OAuth. OAuth remains the best fit for end‑user, interactive scenarios.

Why this matters

Authentication via API token access unlocks new ways to use Atlassian MCP:

• Automate workflows end-to-end: Run MCP tools on a schedule or in response to events, such as sync/triage Jira issues and update Confluence pages.
• Integrate with your infrastructure: Call MCP from backend services, internal platforms, and agents/workers without a logged-in browser user.
• Use MCP where browsers don't exist: Containers, servers, and cron jobs can now authenticate directly while respecting token permissions.

Authentication options for Atlassian MCP

With this new authentication method, you'll have two ways to authenticate with Atlassian MCP:

1. OAuth 2.1 bearer tokens (existing and interactive)

This is the best option for end-user driven scenarios where interactive consent is acceptable. This method uses the standard OAuth 2.1 flow, requires a browser-based consent screen, and is ideal when a human user can approve access.

2. Atlassian API token with Basic Auth (new, non-interactive, and optional)

This is the preferred option for user-scoped automation from non-interactive environments. This method uses a personal API token created by the user and sent via HTTP Basic Auth in the Authorization header (Basic base64(email:api_token)). Tools run with the same permissions as the token owner.

How it works (high-level)

Your MCP client connects to the Atlassian MCP server at:

https://mcp.atlassian.com/v1/mcp

The client includes an Authorization header using Basic Auth with your email and API token:

Authorization: Basic BASE64_ENCODED_EMAIL_AND_TOKEN

MCP tools execute with the permissions associated with that token, enabling access to Jira, Confluence, and other Atlassian apps as permitted.

This design lets us support non‑interactive clients while staying aligned with how Atlassian tokens are created, managed, and revoked today.

In our official documentation, we'll show how the MCP server, tokens, and Atlassian cloud services interact in more detail.

Getting started (preview)

Here's a quick look at how you'll configure the new method in your MCP client once it's available.

1. Create a personal API token

You'll generate a personal API token from your Atlassian account security settings:

• Go to: https://id.atlassian.com/manage-profile/security/api-tokens?autofillToken&expiryDays=max&appId=mcp&selectedScopes=all
• Create a new token for your MCP client.
• If necessary, select the scopes you want your API token to have.
• Store it securely (for example, in your CI/CD secret store or vault).

2. Base64‑encode your email and API token

Create a base64‑encoded string from your email and API token in the format email:api_token:

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

Copy the output — this is what you'll use in your MCP configuration.

3. Configure your MCP client

Here's an example mcp.json configuration using Basic Auth:

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

Or

"atlassian-rovo-mcp": {
  "command": "npx",
  "args": [
    "mcp-remote@latest",
    "https://mcp.atlassian.com/v1/mcp",
    "--header",
    "Authorization: Basic BASE64_ENCODED_EMAIL_AND_TOKEN"
  ]
}

Replace BASE64_ENCODED_EMAIL_AND_TOKEN with the value you generated in the previous step.

Admin settings and controls

This capability is off by default.

Because OAuth allowlists do not apply to agents using API tokens, an Org admin must explicitly enable this feature in order for api tokens to be honored.

Troubleshooting

Agent only discovers two tools

If your agent is only discovering two tools, the most likely cause is an incorrectly encoded token

Your api token scopes are not added properly in case you didn't use Rovo MCP API Token, please review the scopes here https://support.atlassian.com/atlassian-rovo-mcp-server/docs/supported-tools/

Update latest IDE and Desktop

• Please ensure to use https://mcp.atlassian.com/v1/mcp
• Please ensure to update your IDE to latests.
• Please ensure to use mcp-remote@latest

Current limitations and roadmap

Initial limitations

No domain allowlist validation via redirect URIs: Because there is no redirect URI, domain allowlist checks tied to redirects are bypassed; IP allowlist enforcement is enabled as a separate control and is supported for all authentication methods.

On the roadmap

We're exploring support for product and cloudId filters so you can control which products and sites MCP tools can access when authentication via API token access is used.

Learn more and share feedback

• Watch the Atlassian Community post for updates and timelines.
• Identify use cases for authentication via API token (CI/CD, agents, internal platforms) and share feedback in the comments.
• Your feedback will directly shape how we evolve this new authentication method for Atlassian Rovo MCP.

[Ibby]

Rovo MCP Scoped Token

Org Admin Setting to be enabled

[bondansebastian]

Hi, I'm having trouble connecting to the MCP server, I've make sure to follow every steps mentioned in the guide.

1. Enabling Org admin setting 
2. Setting up the API token
   

Are there any missing steps? 

Thank you

[Ibby]

Hey @bondansebastian 

Did you create a new Rovo MCP Token? when 2 tools are showing it either means token encoding issue or it's not using Rovo MCP scoped Token.

[bondansebastian]

Ah, I used a previously created token which is probably is not a Rovo MCP token. It works now! Thanks for the help.