Trying Out the New "OAuth Authentication" Feature of the AWS MCP Server with Kiro CLI

Introduction

On July 9, 2026, AWS MCP Server added support for OAuth 2.0 authentication.

https://aws.amazon.com/about-aws/whats-new/2026/07/oauth-aws-mcp-server/

https://aws.amazon.com/blogs/security/introducing-oauth-support-for-aws-mcp-server/

For details on OAuth authentication for AWS MCP Server, see the following article.

https://dev.classmethod.jp/articles/20260710-aws-mcp-server-oauth/

Until now, using AWS MCP Server required installing the AWS CLI, setting up mcp-proxy-for-aws (via uvx), and preparing local credentials for the AWS CLI. With this OAuth support, a method that lets you connect using only the AWS Sign-In in your browser has been added.

The main changes are summarized in the comparison table below.

In Kiro CLI, which is used in this article, the foundation for MCP OAuth authorization has been put in place over the last two versions.

In this article, I use Kiro CLI 2.12.0 to connect to AWS MCP Server through the OAuth authorization flow. I will verify on a real machine that the role that was active in the browser at the time of OAuth authorization is the one used for AWS operations via MCP.

Official documentation:

• Sign-In with OAuth 2.0（AWS Sign-In User Guide）
• Setting up the AWS MCP Server（Agent Toolkit User Guide）

Verification Details

Verification Environment

Goal

I will show that the following two return different identities within the same Kiro CLI session, confirming that local AWS credentials and OAuth-based MCP server authentication are independent paths.

• The use_aws tool (uses local AWS CLI credentials)
• The aws___call_aws tool (via the MCP server, uses the role authorized through OAuth)

Setup

Creating the IAM User (for Local Credentials)

For this verification, to show that the local and OAuth authentication paths are independent, I created an IAM user mcp-oauth-verify-test with all operations denied.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

Attaching the IAM Policy (OAuth Authorization Target Side)

OAuth authorization is performed based on the AWS Sign-In session that is active in the browser. In this verification, I performed OAuth authorization while switched to a role with AdministratorAccess in the AWS account used for verification.

If you do not have broad permissions such as AdministratorAccess or PowerUserAccess, attach AWSMCPSignInOAuthAccessPolicy to the IAM entity used during OAuth authorization.

Adding the MCP Server

Run the following command in Kiro CLI.

kiro-cli mcp add --name aws-mcp --url https://aws-mcp.us-east-1.api.aws/mcp

This alone registers an OAuth-based MCP server.

Verification Steps

1. Checking Local Credentials

First, I checked the current identity using the local AWS CLI credentials (the use_aws tool).

{
  "UserId": "AIDA****************",
  "Account": "78**********",
  "Arn": "arn:aws:iam::78**********:user/mcp-oauth-verify-test"
}

The IAM user with all operations denied (Deny *), configured in the local profile, was returned.

2. Performing OAuth Authorization

I ran /mcp auth aws-mcp in the Kiro CLI chat screen to start the OAuth authorization flow.

In the MCP panel, the server status becomes ⚠ auth-required, and the status bar shows aws-mcp requires OAuth — Ctrl+y to authenticate. When you press Ctrl+y, the authorization URL is displayed in the terminal, so open it in your browser.

At this point, the browser was already switched to a role in the AWS console. When I pressed the "Authorize" button to complete authorization, the browser displayed "You can close this page now".

Back in Kiro CLI, the authentication request notice in the status bar disappeared, and the status in the MCP panel changed to ● running (9 tools).

3. Checking the Identity via MCP

After OAuth authorization was complete, I ran sts get-caller-identity with the tool via the MCP server (aws___call_aws).

{
  "UserId": "AROA*****************:my-role-name",
  "Account": "78**********",
  "Arn": "arn:aws:sts::78**********:assumed-role/my-role-name/my-role-name"
}

The identity of the role session that I had switched to in the browser was returned.

Comparison of Results

I confirmed that, within the same Kiro CLI session, the local credentials and the credentials via MCP are separated.

Re-authentication (Switching Accounts/Roles)

After switching accounts or roles in the browser, you can re-authenticate from the MCP panel.

1. Open the panel with /mcp
2. Ctrl+R (remove creds) — Deletes the existing OAuth token (the panel display does not change)
3. Ctrl+A (auth) — The server restarts and the status changes to ⚠ auth-required
4. Ctrl+y or Enter — Get the authorization URL and authenticate in the browser

In this verification, by switching to a different role in the browser and then performing the above, I was able to change the role used for AWS operations via MCP.

Summary

AWS MCP Server now supports OAuth authentication. With Kiro CLI 2.12.0, you can connect to AWS MCP Server through OAuth authorization based on the browser's AWS Sign-In session, without preparing an AWS CLI profile or access keys on your local machine.

This verification confirmed that, independently of the local AWS CLI credentials, the role that was active in the browser at the time of OAuth authorization is used for AWS operations via MCP. Even within the same Kiro CLI session, the path that uses local AWS CLI credentials and the path via the OAuth-authorized AWS MCP Server are separated.

With the conventional aws login and aws sso login, browser-based authentication was also possible. However, to enable or refresh AWS credentials while working in Kiro CLI, you had to either temporarily suspend Kiro CLI or open another terminal and run commands.

With this OAuth support, after registering the MCP server, you can start the authorization flow from /mcp auth in Kiro CLI, complete AWS Sign-In in the browser, and proceed directly to AWS operations via MCP. The step of switching terminals to run AWS CLI authentication commands is no longer needed, and the flow to get started with AWS MCP Server has become simpler.

If you want to keep no AWS CLI credentials locally and authorize use of the MCP server through the browser's Sign-In session only when needed, this is easier to handle than the conventional aws login / aws sso login + mcp-proxy-for-aws approach. In environments where local credentials can be protected with EC2 instance profiles or MFA/1Password, the SigV4 method also remains an option.