aws loginで使用するIAM権限と、権限不足時の挙動を確認してみた

aws loginを実行する際に必須となるIAM権限について、実機での動作検証を通じて確認します。ポリシー有無による成否の違いと、SignInLocalDevelopmentAccessマネージドポリシーに含まれる各actionの役割を確認します。

tsureyama.sota

2026.10.30

AWS CLIの認証方法の一つに、aws login という手法があります。

これはマネジメントコンソールの認証を経由する方法で、aws公式ドキュメントでも推奨されています。
Authentication and access credentials for the AWS CLI
検証環境で試したところエラーが生じ、特定のポリシーが必要なことに気づきました。

この記事では、aws login に必要なポリシーを深掘りし、権限の有無による挙動の違いを確認します。
 結論の先取り...ユーザーガイドに、SignInLocalDevelopmentAccessポリシーの付与が前提と明記されています。

Login for AWS local development using console credentials
Ensure the IAM identity has the appropriate permissions. Attach the SignInLocalDevelopmentAccess managed policy to your IAM user, role, or group. If you sign in as a root user, no additional permissions are required.
SignInLocalDevelopmentAccessはAWS管理ポリシーの一つで、中身は以下のようになっています。
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "signin:AuthorizeOAuth2Access",
                "signin:CreateOAuth2Token"
            ],
            "Resource": "arn:aws:signin:*:*:oauth2/public-client/*"
        }
    ]
}
signin:AuthorizeOAuth2Accessとsignin:CreateOAuth2Tokenという2つのactionが許可されています。
各actionの詳細をドキュメントで確認しました。

AuthorizeOAuth2Access
Grants permission to authenticate through a browser and obtain an OAuth 2.0 authorization code for credential exchange.
CreateOAuth2Token
Exchanges an authorization code or refresh token for an OAuth 2.0 access token and refresh token.
それぞれ
signin:AuthorizeOAuth2Access: ブラウザ経由でOAuth2.0用のクレデンシャルを取得する権限
signin:CreateOAuth2Token: OAuth2.0用トークンを生成・更新する権限
という役割です。
signin:AuthorizeOAuth2Accessによりブラウザ認証が成功し、signin:CreateOAuth2Tokenにより手元にトークンが生成され、15分おきに更新できるようになります。
 この記事で確認することこの記事では、以下の2観点5パターンを実際に試してみます。
ポリシー（SignInLocalDevelopmentAccess）の有無による、aws login実行時の挙動

1-A. ポリシーなしの場合

1-B. ポリシーありの場合
ポリシー（SignInLocalDevelopmentAccess）の2つのactionのうち、片方だけが許可されていた場合の挙動

2-A. signin:AuthorizeOAuth2Accessの許可だけの場合

2-B. signin:CreateOAuth2Tokenの許可だけの場合

2-C. aws login成功後にsignin:CreateOAuth2Tokenの許可を外した場合
 確認1. ポリシー（SignInLocalDevelopmentAccess）の有無による、aws login実行時の挙動の違い 事前準備: 検証用IAMユーザーの作成検証環境に、コンソールログインだけを許可したIAMユーザを作成します。

※MFAは有効化させています。
まずは何のポリシーも付与せず、権限0の状態です。
コンソールログインは成功しています。

また、ローカルマシン上の.aws/configは一時的に削除しています。
 1-A. ポリシーなしの場合ポリシー未付与の状態でaws loginコマンドを実行します。

regionの指定を求められますが、今回は何も指定せずデフォルトで進みました。
$aws login
No AWS region has been configured. The AWS region is the geographic location of your AWS resources.

If you have used AWS before and already have resources in your account, specify which region they were created in. If you have not created resources in your account before, you can pick the region closest to you: https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions.html.

You are able to change the region in the CLI at any time with the command "aws configure set region NEW_REGION".
AWS Region [us-east-1]:
region指定を終えると、認証用のブラウザが開きます。
Attempting to open your default browser. If the browser does not open, open the following URL.
If you are unable to open the URL on this device, run this command again with the '--remote' option.
Continue to Sign inで進むと、コンソールログイン時と同じ画面が開きます。
アカウント名・ユーザ名・パスワードを入れるとMFAに進みます。
ワンタイムパスワードを入力すると、Authentication failedの表示とともにログイン画面に戻されます。


※ターミナル側は返答を待ち続けているので、Ctrl+Cで止めました。
また、事前にコンソールログインした状態でaws loginを実行すると、既存のセッションを利用するかの確認が表示されます。

ここから進むと、400 Bad Requestが返ります。
ポリシーなしでは認証に失敗することが確認できました。
 1-B. ポリシーありの場合次に、SignInLocalDevelopmentAccess ポリシーをIAMユーザにアタッチして同じことをします。

[16:38:11]$aws login
No AWS region has been configured. The AWS region is the geographic location of your AWS resources.

If you have used AWS before and already have resources in your account, specify which region they were created in. If you have not created resources in your account before, you can pick the region closest to you: https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions.html.

You are able to change the region in the CLI at any time with the command "aws configure set region NEW_REGION".
AWS Region [us-east-1]:
ブラウザ認証画面が開きますが、1度目と同様なのでスクリーンショットは省略します。

MFA入力後、今度は認証が通り、以下の画面が表示されました。

ターミナル側も認証結果を受け取りました。
Updated profile default to use arn:aws:iam::123456789012:user/aws_login_test credentials.
実際にawsコマンドの疎通も確認できます。
$aws sts get-caller-identity
{
    "UserId": "XXXXXXXXXXXXXXXXXXXXX",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/aws_login_test"
}
SignInLocalDevelopmentAccessを付与することで aws login が成功することを確認できました。
 [補足]aws loginによる認証情報の実体aws loginで使用する認証情報は15分おきに、最大12時間更新されます。

認証情報は、linux, macOSは~/.aws/login/cache, windowsは%USERPROFILE%\.aws\login\cacheに保存されています。

※15分で切れますが、平文で保存されている点は要注意です。
$ls -l ~/.aws/login/cache/
total 16
-rw-------@ 1 xxx  xxx  4582 10月 29 17:50 adb314bc7c5b932887bb7e5920ab311e41d0df49b82c57ab71589fdffd91b611.json
Login for AWS local development using console credentials
The AWS CLI and SDKs will automatically refresh the cached credentials every 15 minutes as needed. The overall session will be valid for up to the set session duration of the IAM principal (maximum of 12 hours), after which you must run aws login again.
aws logoutコマンドを実行すると、このキャッシュが削除されます。
$aws logout
Removed cached login credentials for profile 'default'. Note, any local developer tools that have already loaded the access token may continue to use it until its expiration. Access tokens expire in 15 minutes.

$ls -l ~/.aws/login/cache/
total 0
 確認2 ポリシー（SignInLocalDevelopmentAccess）の2つのactionのうち、片方だけが許可されていた場合の挙動上記の検証で付与したAWS管理ポリシーでは、具体的には以下2つのactionを許可していました。
signin:AuthorizeOAuth2Access
signin:CreateOAuth2Token
次の確認では、上記の片方しか許可していないカスタマー管理ポリシーを作成し、検証用ユーザに紐付けてみます。
 2-A. signin:AuthorizeOAuth2Accessの許可だけでaws login を実行した場合signin:AuthorizeOAuth2Accessを許可すると、ブラウザ経由でOAuth2.0用のクレデンシャルを取得できるようになります。
以下のようにポリシーを付与しています。

aws loginを実行したところ、ブラウザの認証は先ほどと同様に通りました。

しかし、ターミナル側ではエラーが返ってきました。
[19:05:10]$aws login
~略~

aws: [ERROR]: Unable to create or refresh login credentials due to insufficient permissions. You may be missing permission for the 'signin:CreateOAuth2Token' action.
エラーメッセージで、まさに今回削ったsignin:CreateOAuth2Tokenが欠けていないかと指摘されています。
 2-B. signin:CreateOAuth2Tokenの許可だけでaws login を実行した場合signin:CreateOAuth2Tokenを許可すると、OAuth2.0用トークンを生成・更新できるようになります。
以下のようにポリシーを付与しています。



aws loginを実行したところ、ポリシーなしでテストした時と同様にブラウザ認証で失敗しました。

 2-C. aws loginの成功後、signin:CreateOAuth2Tokenの許可を削除した場合2-A, 2-B両方のポリシーを付与した状態でaws loginした後、2-Bのポリシー（signin:CreateOAuth2Tokenの許可）を外して15分ほど待ってみます。
まず、aws loginしてawsコマンドが打てることを確認します。
$aws login; aws sts get-caller-identity; date
Attempting to open your default browser. If the browser does not open, open the following URL.
If you are unable to open the URL on this device, run this command again with the '--remote' option.

~略~

Updated profile default to use arn:aws:iam::123456789012:user/aws_login_test credentials.
{
    "UserId": "XXXXXXXXXXXXXXXXXXXXX",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/aws_login_test"
}
2026年 10月29日 木曜日 19時32分22秒 JST
打鍵した時刻は19:32でした。
ここからsignin:CreateOAuth2Tokenのポリシーを外して、signin:AuthorizeOAuth2Accessだけの状態で15分待ちます。

※確認2-Aと同じ状態です

~待機~
（目を離していたら30分近く経ってしまいました）

19:59に再び打鍵したところ、token更新に失敗していることが確認できました。
$aws sts get-caller-identity; date

aws: [ERROR]: Unable to create or refresh login credentials due to insufficient permissions. You may be missing permission for the 'signin:CreateOAuth2Token' action.
2026年 10月29日 木曜日 19時59分09秒 JST
 まとめこの記事では、以下を確認しました。
aws loginにはSignInLocalDevelopmentAccessAWS管理ポリシーが必要
上記ポリシーでは以下2つのactionを許可している
signin:AuthorizeOAuth2Access: ブラウザ経由でOAuth2.0用のクレデンシャルを取得する権限
signin:CreateOAuth2Token: OAuth2.0用トークンを生成・更新する権限

ポリシーが不足していた場合、ブラウザからのコンソール接続自体はできるのに aws login の認証は失敗するという状態になります。

（個人的にはこのコンソール接続自体はできる点でハマりました）
この記事がどなたかの参考になれば幸いです。最後までご覧いただきありがとうございました！
 aws login関連の 参考ブログaws loginに関するブログは既に沢山出ていますが、一部をご紹介します。
AWS CLIの 新機能 aws login コマンドを試してみた

aws loginのリリース直後の記事で、使い方が詳しく載っています。
AWS CLIのaws loginコマンドをリモートマシンで使う

リモート端末でaws loginを実行した場合の検証・解説記事です。
aws login コマンドを実行したときに何が起きているか調べてみた

aws login実行時にconfig, cacheが更新される動きを検証する記事です。
aws loginしてもdefaultのcredentialsが優先される場合の対処法と認証情報の優先順位

aws loginと他の認証情報との優先関係の検証記事です。