OAuth 2.1 authentication for AWS MCP Server

AWS MCP Server supports OAuth 2.1 authorization through AWS Sign-in. OAuth-compatible MCP clients — including Claude Code, Cursor, Gemini CLI, Kiro, and GitHub Copilot — can connect directly to AWS MCP Server. No local proxy software is required. For an overview of how OAuth works with AWS Sign-in, see OAuth with AWS Sign-in overview and AWS MCP Server in the AWS Sign-in User Guide.

With OAuth, your MCP client authenticates using standard OAuth authorization flows while continuing to rely on existing IAM identities, permissions, and organizational controls. AWS Sign-in acts as the OAuth authorization server, issuing scoped access tokens that AWS MCP Server accepts as bearer tokens.

Prerequisites

Before using OAuth with AWS MCP Server, ensure the following:

Attach the managed policy

aws iam attach-role-policy \
  --role-name MyRole \
  --policy-arn arn:aws:iam::aws:policy/AWSMCPSignInOAuthAccessPolicy

Or use a custom IAM policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "signin:AuthorizeOAuth2Access",
        "signin:CreateOAuth2Token"
      ],
      "Resource": "arn:aws:signin:*:*:service-principal/aws-mcp.amazonaws.com"
    }
  ]
}

Configure your MCP client for OAuth

Add the AWS MCP Server endpoint directly to your MCP client. Unlike the SigV4 proxy method, OAuth-compatible clients connect to the server URL without requiring mcp-proxy-for-aws or uvx.

For other clients, see your MCP client documentation for instructions on adding a remote MCP server. Use the endpoint URL https://aws-mcp.us-east-1.api.aws/mcp (or the endpoint for your preferred Region).

https://aws-mcp.us-east-1.api.aws/mcp?oauth=initialize

Authenticate with OAuth

When you first invoke an AWS MCP Server tool, your MCP client opens a browser to AWS Sign-in. Sign in with your existing AWS credentials, review the consent page showing the application requesting access, and authorize access.

After you grant consent, AWS Sign-in issues short-lived OAuth tokens. Your MCP client uses these tokens to interact with AWS MCP Server on your behalf. Access tokens remain valid for 1 hour. AWS Sign-in automatically refreshes them using refresh tokens (valid for up to 12 hours), so you do not need to sign in again during your session.

If you already have an active AWS Sign-in session, AWS Sign-in can reuse that session to complete the authorization flow without requiring you to sign in again.

OAuth authorization flows

AWS Sign-in supports two authorization flows for accessing AWS MCP Server:

Interactive user access (Authorization Code flow)

If you use an MCP client on your local machine, AWS uses the OAuth authorization code flow with Proof Key for Code Exchange (PKCE). This flow supports:

The flow works as follows:

Programmatic and agentic access (Client Credentials flow)

AI agents and automated applications can access AWS MCP Server without interactive browser sign-in by using the OAuth client credentials flow. The application authenticates using its existing AWS credentials (SigV4) to obtain a short-lived OAuth access token.

This flow is designed for:

Obtain an access token

Run the following AWS CLI command to request a token:

aws signin create-oauth2-token-with-iam \
    --grant-type client_credentials \
    --resource aws-mcp.amazonaws.com \
    --region us-east-1

The response includes an access token:

{
    "accessToken": "<token>",
    "tokenType": "Bearer",
    "expiresIn": 3597
}

Include the value of accessToken as an Authorization: Bearer <token> header in your MCP client configuration. Check your client's documentation for how to include this header.

AWS Sign-in does not issue a refresh token for the client credentials flow. Access tokens remain valid for 1 hour. For more information, see AWS MCP Server in the AWS Sign-in User Guide.

Access control for OAuth

OAuth authorization does not grant additional AWS permissions to the MCP client. The MCP client can only act within the permissions already granted to you. IAM policies, SCPs, RCPs, permission boundaries, and data perimeter controls still determine what actions are allowed.

OAuth access uses short-lived tokens. The same IAM permissions and organizational controls that apply to other forms of AWS access also govern OAuth access.

Governing OAuth access

AWS Sign-in provides condition keys that you can use to control how OAuth is used within your organization. For a complete reference, see OAuth condition keys reference in the AWS Sign-in User Guide.

For example, the following policy restricts OAuth access to localhost redirects only:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "signin:AuthorizeOAuth2Access",
      "Resource": "arn:aws:signin:*:*:service-principal/aws-mcp.amazonaws.com",
      "Condition": {
        "StringLike": {
          "signin:OAuthRedirectUri": [
            "http://localhost:*/*",
            "http://127.0.0.1:*/*"
          ]
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "signin:CreateOAuth2Token",
      "Resource": "arn:aws:signin:*:*:service-principal/aws-mcp.amazonaws.com"
    }
  ]
}

Token management

Token lifecycle

Token revocation

AWS Sign-in automatically revokes refresh tokens in the following situations:

AWS Sign-in also provides token introspection (signin:IntrospectOAuth2Token) and token revocation (signin:RevokeOAuth2Token) APIs. You can use these APIs to validate the status of individual OAuth tokens and revoke specific refresh tokens without affecting other active sessions.

For example, if a refresh token is accidentally exposed in a source code repository, administrators can revoke only the affected refresh token without requiring users to reauthorize unrelated applications.

Monitoring OAuth activity

AWS CloudTrail records OAuth-related activities, including authorization requests, token issuance, token revocation, and token introspection events. CloudTrail logs capture details such as the OAuth client, target AWS MCP Server, redirect URI, authorization flow, and associated sign-in session.

When you make API calls using OAuth access tokens, AWS includes the aws:SignInSessionArn context key. Use this context key to correlate API activity with the originating OAuth sign-in session.

The following example shows a CloudTrail log entry for an AuthorizeOAuth2Access event:

{
    "eventVersion": "1.11",
    "userIdentity": {
        "type": "AssumedRole",
        "principalId": "AROAEXAMPLE:testuser",
        "arn": "arn:aws:sts::111111111111:assumed-role/Admin/testuser",
        "accountId": "111111111111"
    },
    "eventTime": "2026-07-08T05:09:00Z",
    "eventSource": "signin.amazonaws.com",
    "eventName": "AuthorizeOAuth2Access",
    "awsRegion": "us-west-2",
    "sourceIPAddress": "203.0.113.1",
    "requestParameters": {
        "resource": "https://aws-mcp.us-west-2.api.aws/mcp",
        "redirect_uri": "http://127.0.0.1:60432/oauth/callback",
        "code_challenge_method": "S256",
        "client_id": "arn:aws:signin:us-west-2::external-client/dcr/609544da-example"
    },
    "additionalEventData": {
        "success": "true"
    },
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "recipientAccountId": "111111111111"
}

The following example shows a CloudTrail log entry for a CreateOAuth2Token event:

{
    "eventVersion": "1.11",
    "userIdentity": {
        "type": "AssumedRole",
        "principalId": "AROAEXAMPLE:testuser",
        "arn": "arn:aws:sts::111111111111:assumed-role/Admin/testuser",
        "accountId": "111111111111"
    },
    "eventTime": "2026-07-08T05:10:04Z",
    "eventSource": "signin.amazonaws.com",
    "eventName": "CreateOAuth2Token",
    "awsRegion": "us-west-2",
    "sourceIPAddress": "203.0.113.2",
    "requestParameters": {
        "resource": "https://aws-mcp.us-west-2.api.aws/mcp",
        "client_id": "arn:aws:signin:us-west-2::external-client/dcr/609544da-example"
    },
    "additionalEventData": {
        "signInSessionArn": "arn:aws:signin:us-west-2:111111111111:session/example-uuid",
        "success": "true"
    },
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "recipientAccountId": "111111111111"
}