aws loginで400エラー？ブラウザのマネコンセッションが必要な理由を調べてみた

• URL: https://dev.classmethod.jp/articles/aws-login-400-error-browser-session
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: aws login コマンド実行時に 400 Bad Request が発生する原因は、ブラウザのマネコンセッションが目的のアカウントにログインしていないこと。スイッチロール構成でベースアカウントの IAM ユーザーにだけログインしており、スイッチロール先には権限がないと 400 エラーになる。解決策はブラウザで先にスイッチロール先のアカウントにログインしてから aws login を実行すること。

詳細

aws login は AWS マネジメントコンソールにログイン済みのブラウザセッションを流用して CLI の一時クレデンシャルを取得するコマンド。2025年11月19日にリリースされた。OAuth2.0 の拡張仕様 PKCE（RFC 7636）を使い、CLI が生成した秘密文字列 code_verifier のハッシュ化値 code_challenge を URL に含める一方、code_verifier 自体は CLI から直接 /v1/token に POST する設計で、認可コードを窃取されてもトークンを盗まれない仕組みになっている。aws login の処理フローはコード生成→ブラウザ起動→認可リクエスト送信→Auth サーバーがセッション情報で判定して認可コード返却→CLI がトークンリクエスト送信→クレデンシャル発行という流れで、ブラウザのセッション情報が認可判断の材料となる。セッションが権限をもたないロール状態だと Auth サーバーは 400 Bad Request を返す。ブラウザセッション状態別の挙動は、完全未ログイン時はサインインオプション画面が表示される。ベースアカウントのみログイン（スイッチロール前）でベースアカウント IAM ユーザーに SignInLocalDevelopmentAccess がない場合、400 Bad Request が発生。スイッチロール先にログイン済みなら目的のアカウントを対象とした認可画面が立ち上がり、成功する。補足として aws login –remote オプションを使うと localhost のコールバックサーバーを使わず、URL にアクセスして返却された認可コードを手動で貼り付けるファイアウォールブロック時の回避策が可能。