Configuring OAuth 2.1

OAuth 2.1 is the recommended authentication method for interactive, user-driven scenarios with the Atlassian Rovo MCP Server.

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.
5. MCP validates the token, enriches it with user and product context, and forwards requests to the appropriate Atlassian products and tools.

Configure your MCP client

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

1
2
{
  "mcpServers": {
    "atlassian-rovo-mcp": {
      "url": "https://mcp.atlassian.com/v1/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.

Security model

• 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.
• Tokens 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.

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.