aws loginで400エラー？ブラウザのマネコンセッションが必要な理由を調べてみた
はじめに
AI事業本部の竹口です。
2025年11月19日、AWS CLIの認証をブラウザベースで実現する新コマンド 「aws login」 がリリースされました。
自分は普段 aws-vault exec で認証を行っていたのですが、セッションの有効期限が短くDXが悪い + サブプロセスに環境変数として一時クレデンシャルを注入する方式はClaude Codeセッションとの相性がイマイチ と感じたため、 aws login を試してみることにしました。
しかしながら、実際に試してみると ログイン画面 で 400 Bad Request が発生。目的のアカウント ( スイッチロール先 ) の IAM ロール権限は問題ない様子。なんなら先日試しでやったときはうまく動いていた。という不可解な状況に陥りました。
結論としては、 ブラウザのマネコンセッションで、目的のアカウントにログインしていない ことが原因でした。
ここでは、同じ状況に陥った方への 解決 How to と 何故それで解決するのか原因の解説 を行います。
aws login とは
aws login とは、ブラウザの認証 を流用して、CLIの一時クレデンシャルを取得できるコマンドです。AWSマネジメントコンソールにログイン済みのブラウザで承認するだけで、ローカルのAWS CLIが利用できるようになります。
既存の AWS マネジメントコンソールのサインイン認証情報を使用して、AWS サービスにプログラムでアクセスできます。ブラウザベースの認証フローの後、AWS は AWS CLI、AWS Tools for PowerShell、AWS SDK などのローカル開発ツールで動作する一時的な認証情報を生成します。
詳細な説明と設定方法については先行記事があるため、そちらを確認いただければと思います。
筆者の環境
私の環境は、「ベースアカウントのIAMユーザー + スイッチロール」構成でした。
ベースアカウントの IAM ユーザーでマネコンにログインし、スイッチロールで作業アカウントに入る運用です。
このとき、ベースアカウントの IAM ユーザーには、SignInLocalDevelopmentAccess 権限は付与されておらず 、スイッチロール先のアカウントには権限が付与されていました。
起きたこと
ブラウザから ベースアカウントの IAM ユーザー にログインし、CLI にて aws login コマンドを叩きました。
$ aws login --profile <profile名>
> 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.
>
>
> https://ap-northeast-1.signin.aws.amazon.com/v1/authorize?response_type=code&client_id=arn%3Aaws%3Asignin%3A%3A%3Adevtools%2Fsame-device&state=...&code_challenge_method=SHA-256&scope=openid&redirect_uri=http%3A%2F%2F127.0.0.1%3A55531%2Foauth%2Fcallback&code_challenge=...
するとブラウザに遷移し、下図のように ベースアカウントの承認画面が表示され、承認を進めようとすると 400 Bad Request Error が発生しました。
URLは正常に生成され、ブラウザは開いていました。そのため、コマンド自体は正常に動作しており、問題はブラウザ側で起きていました。
`aws login` が生成する `client_id` と `code_challenge` パラメータとは？
client_id→ OAuthクライアント ( = AWS CLI ) の識別子- 「どのアプリがOAuthリクエストしているか」をAWSに伝えるラベル
code_challenge→ PKCE ( Proof Key for Code Exchange ) 用のパラメータ- CLIが生成した秘密文字列
code_verifierの SHA-256 ハッシュ - PKCEとは、 認可コードを窃取されても、トークンは取れないようにする 仕組み
- AWS クレデンシャルの取得条件として、認可コード ( code ) に加えて秘密文字列 ( code_verifier ) を必要とする OAuth2.0 の拡張仕様 ( RFC 7636 )
- 攻撃者が 認可コードを窃取しても、
code_verifierも一緒に窃取できない限り は最初のリクエストと同一クライアントであることを証明できず、 AWS クレデンシャルを発行できない(AWSリソースにアクセスすることができない) - URL には
code_challenge（ハッシュ化された値）のみ載り、code_verifier自体は載らない。 平文のcode_verifierはブラウザを経由しない ( CLI から/v1/tokenに直接 POST する)
- CLIが生成した秘密文字列
解決 How to : ブラウザで先にスイッチロールしてからaws loginする
前述した通り、aws login とは、ブラウザの認証 を流用して、CLIの一時クレデンシャルを取得できるコマンドです。ブラウザのセッション状態が 目的のアカウントにログイン された状況でなく、一歩手前の ベースアカウントの IAM ユーザーにログイン した状態で止まっていました。同 IAM ユーザーには SignInLocalDevelopmentAccess 権限 が付与されていないため、権限不足で 400 Bad Request Error が発生していました。
よって以下の手順を取ることで、目的のアカウントでの aws login による一時クレデンシャルの取得が可能となります。
1. ブラウザでマネコンにログイン(ベースアカウントのIAMユーザー認証)
※権限の関係でアプリケーションのリストが表示されていません
2. 目的のアカウント/ロールにスイッチロールする
3. ターミナルに戻って aws login --profile <プロファイル名>
$ aws login --profile <プロファイル名>
4. ブラウザの認可画面から目的のセッションを選択
5. 成功メッセージを確認
400 Bad Request Error
§筆者の環境 に記述した通り、筆者環境において、ベースアカウントの IAM ユーザーにはSignInLocalDevelopmentAccess 権限が付与されていませんでした。そのため、400 Bad Request Error が発生した直接の原因は、IAM ロールの権限不足 になります。
権限不足が原因なので、403 Errorで返して欲しいと思わないでもないです
先日試したときに aws login に成功していたのは、たまたまブラウザでスイッチロール済の状態で CLI からの aws login を行ったためでした。
aws login における 400 Error は、IAM ロール権限不足によって引き起こされます。スイッチロール構成ではない状況で 400 Error が確認されている場合は、目的のアカウントに適切な権限が付与されているかを確認いただくのが良いかと思います。
補足: ブラウザのセッション状態ごとの挙動
まとめると下表の通りとなっていますが、実際に画面を確認しながら解説します。
| ブラウザの状態 | aws loginの挙動 |
|---|---|
| 完全に未ログイン | サインインオプション画面が表示される。ログインすれば進む |
| ベースアカウントのみログイン(スイッチロール前) | ベースアカウントのロールにSignInLocalDevelopmentAccessがない場合 → 400 Bad Request |
| スイッチロール先にログイン済み | セッション選択画面が表示される。選択すれば成功 |
完全に未ログイン の状態
下図のように、任意のアカウントへのログイン画面が立ち上がります。
この状態からでも、「Continue with Root or IAM user 」からログインを行えば aws login に成功します。
ベースアカウントのみログイン (スイッチロール前) の状態
マネジメントコンソールからベースアカウントにログインします。
※権限の関係でアプリケーションのリストが表示されません
この状態から aws login を実行すると、下図のようにベースアカウントを対象としたブラウザ承認画面が立ち上がります。
しかしベースアカウントの IAM ユーザーには SignInLocalDevelopmentAccess 権限 が付与されていないため、 400 Bad Request Error が表示されます。
スイッチロール先にログイン済み の状態
マネジメントコンソールからベースアカウントにログインし、スイッチロールします。
この状態から aws login を実行すると、下図のように目的のアカウントを対象としたブラウザ承認画面が立ち上がります。
SignInLocalDevelopmentAccess 権限 が付与されたアカウントでは、承認に成功します。
補足: --remoteオプション
aws login コマンドには、--remote オプションが提供されています。こちらはCLI上に表示されたURLにアクセスして承認を行い、返却された認可コードを手動で貼り付ける方式になります。
$ aws login --profile <プロファイル名> --remote
このオプションではlocalhostのコールバックサーバーを使わないため、ファイアウォールやセキュリティがlocalhostポートをブロックする際の回避策として扱うことができます。
なぜブラウザのセッションが必要なのか
aws login は、既存のセッションの 認証を再利用 する設計になっています。
aws login の後、内部的には以下の流れで認証と認可コード・トークンの発行が行われます。
- 秘密文字列 ( code_verifier ) 生成
- code_challenge 生成 ( code_verifier のハッシュ化 )
- ブラウザを立上 ( /v1/authorize?code_challenge=... )
- code_challenge や client_id が URL に含まれる
- ブラウザが Auth サーバーに認可リクエストを送信 ( GET /v1/authorize + client_id + code_challenge + redirect_uri )
- ブラウザのセッション情報で判定し、認可コードの発行を判断する
- セッション情報の判定方法は公式に発表されていないが、Cookieを削除すると未ログイン扱いになることを確認した
- Auth サーバーからブラウザに 302 redirect + 認可コード ( code ) 返却
- ブラウザから CLI に、localhost を経由して code を送信
- CLI が Auth サーバーに トークンリクエストを送信 ( POST /v1/token + code + code_verifier )
- Auth サーバーにて code_verifier のハッシュ化した値が code_challenge と一致するか判定
- Auth サーバーが CLI に発行した AWS の一時クレデンシャルを送信
CLIは認証情報を一切送らず、ブラウザのセッション情報が「この人に認可コードを出していいか」の判断材料となります。
そのため、「④ブラウザが Auth サーバーに認可リクエストを送信」にて認可コードを発行しても良い権限を持ったセッションが見つからない場合、Auth サーバーは 400 Bad Request Error を返却します。
aws login とは、「ログインするコマンド」ではなく「既存セッションを借りるコマンド」なのです。
その他の失敗パターン
aws login 失敗時の他パターンはこちらになります。
| 症状 | 原因 | 対処 |
|---|---|---|
| 400 Bad Request | ブラウザでログイン中のロールにSignInLocalDevelopmentAccessがない(スイッチロール環境でベースアカウントのロールに権限がないケース等) |
SignInLocalDevelopmentAccessが付与されたロールでログインした状態にする(= スイッチロール先にログインしてからリトライ) |
| ExpiredToken / AccessDenied | 既存の~/.aws/credentialsが優先されている |
--profileで明示指定、または古いcredentialsを削除 |
| ファイアウォールポップアップ | localhostコールバックサーバーがブロックされている | aws login --remoteを使用 |
ExpiredTokenについては、臼田さんの解説記事が詳しいためおすすめです。
ファイアウォールにブロックされた場合の対処方法は公式Docsに記載があります。
まとめ
aws login はブラウザの既存セッションを再利用する設計でした。そのため、スイッチロール先のアカウントで作業を行う場合には、先にブラウザでスイッチロール先へのログインを完了してから aws login コマンドを叩く必要がありました。
また本コマンドの利用には、SignInLocal DevelopmentAccess 権限の付与が前提にあります。 400 Bad Request Error が発生した際には、以下の点を確認してみるといいかもしれません。
- 目的のアカウントに対して、適切な権限が付与されているか
- 目的のアカウントでログインを完了しているか
この記事がどなたかの役に立ちましたら幸いです。
参考情報ソース
