Configuring OAuth 2.1

OAuth 2.1 is the recommended authentication method for interactive, user-driven scenarios with the Atlassian Rovo MCP Server. For non-interactive use cases, use authentication via API token instead.

How the OAuth flow works

When you use OAuth authentication with MCP:

1. The MCP client initiates an OAuth 2.1 authorization flow.
2. The user is redirected to Atlassian to review and grant access on a consent screen.
3. After the user consents, the client receives an access token.
4. The client sends this token to MCP in the Authorization header as Authorization: Bearer <access_token>.
5. MCP validates the token, enriches it with user and product context, and forwards requests to the appropriate Atlassian apps and tools.

Configure your MCP client

Configure your MCP client to call the MCP server with an OAuth 2.1 bearer token:

1
2
3
4
5
6
7
8
9
10
11
{
  "mcpServers": {
    "atlassian-rovo-mcp": {
      "url": "https://mcp.atlassian.com/v2/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_OAUTH_ACCESS_TOKEN"
      }
    }
  }
}

Replace YOUR_OAUTH_ACCESS_TOKEN with a valid OAuth 2.1 access token obtained from the OAuth flow. The exact way you obtain this token depends on your app or integration - for example, using the OAuth 2.1 authorization code grant.

Atlassian apps and scopes

The OAuth consent screen determines which Atlassian apps and scopes the client can access. MCP uses this information to:

• Load the compatible set of tools.
• Enforce access control according to the user's permissions.
• Route requests to the correct Atlassian sites.

If scopes change, users may need to re-consent. See Supported tools for the scope required by each permission group.

Cloud IDs and allowlists

• With OAuth 2.1, access tokens are typically consented for a specific cloud ID (site). MCP validates that requests are made against the correct cloudId associated with the token, so tokens are only used for the sites they were granted for.
• Domain and redirect allowlists can be enforced as part of the OAuth redirect configuration, so redirects only occur to trusted domains configured in your OAuth app.

Security best practices

• Tokens are user-specific and are never shared between users.
• Use official OAuth flows - avoid custom or hardcoded tokens.
• If permissions are updated, you may need to re-authorize the client.

Common authentication issues

When to use API token instead

For scenarios where you cannot use an interactive OAuth flow (for example, backend services or CI/CD pipelines), use authentication via API token instead.