aws sso loginは、IAM Identity Centerのアクセスポータルにブラウザでサインインし、手元のAWS CLIとSDKに一時認証情報を渡すコマンドです。先にaws configure ssoでconfigへsso-sessionを書いておく必要があり、旧形式のままだと8時間で切れて自動更新も効きません。設定の書き方、PKCEとデバイスコードの使い分け、WSL2での対処、2つの期限の関係、Claude CodeやDockerへの受け渡し、エラー文言ごとの直し方を、AWS CLI 2.38.5での実測を交えて扱います。
まとめ：aws sso loginで押さえるsso-session設定と2種類の期限
設定は[sso-session]セクションを持つ推奨形式で書き、sso_registration_scopes = sso:account:accessまで明記します。refresh tokenを受け取るにはこのスコープが要り、行を省くとデバイスコード認可では1時間ごとのアクセストークン更新が働きません。旧形式の設定は、後述の手順で推奨形式へ移行します。
期限は2本立てです。アクセスポータルのセッション（既定8時間、15分〜90日で変更可）と、権限セットのセッション（既定1時間、最大12時間）が別々に効きます。セッションが生きている間にaws sso loginを打ち直しても、ポータル側の期限は延びません。ブラウザでの本人確認が前提のコマンドなので、CI／CDや無人のバッチでは採用せず、OIDCやIAMロールに寄せてください。
aws configure ssoでsso-sessionを設定する手順
aws sso loginは、どのポータルへ、どのアカウントとロールで入るかをconfigから読み取ります。ウィザードで作ってから手で整える流れが確実です。IAMユーザーからAWS SSOへ移る途中なら、棚卸しと権限セットのコード化をAWS SSOへの移行手順：IAMユーザー棚卸しから権限セットのTerraform化までで先に済ませてください。AWS CLI自体がv1のままなら、AWS CLIのインストールと運用でv2へ入れ替えます。本記事で扱うCLI v2では、2.9以降がセッション管理に対応します。
aws configure ssoの対話設定とstart URL・SSOリージョンの確認
aws configure ssoを実行すると、セッション名、start URL、SSOリージョン、登録スコープの4つを順に聞かれます。登録スコープは2.38.5ではsso:account:accessが既定値として表示されるので、そのままEnterで進めます。公式のCLIユーザーガイドによれば、start URLとSSOリージョンはアクセスポータルで権限セットを選び、「Access keys」リンクの「IAM Identity Center credentials」欄で確認できます。CLI 2.22.0以降は、start URLの代わりにIdentity Centerコンソールのダッシュボードにある「Issuer URL」も使えます。
$ aws configure sso
SSO session name (Recommended): my-sso
SSO start URL [None]: https://my-sso-portal.awsapps.com/start
SSO region [None]: ap-northeast-1
SSO registration scopes [sso:account:access]:
ブラウザで承認すると、使えるアカウントと、そのアカウントで割り当てられた権限セットが順に一覧で出ます。候補が1つしかなければCLIが自動で選び、質問を飛ばします。
There are 2 AWS accounts available to you.
> dev, [email protected] (111122223333)
prod, [email protected] (444455556666)
There are 2 roles available to you.
> PowerUserAccess
ReadOnlyAccess
Default client Region [None]: ap-northeast-1
CLI default output format (json if not specified) [None]: json
Profile name [PowerUserAccess-111122223333]: dev
SSOリージョンはIdentity Centerを有効化したリージョンで、既定リージョンと違っていて構いません。CLI 2.36.50以降は、手元でAIコーディングエージェントが検出されると、ウィザードの最後にAgent Toolkitの導入を勧める質問が出ます。変更履歴のとおり、neverと答えるか、環境変数AWS_CLI_AGENT_TOOLKIT_HINT_DISABLED=trueで止められます。
configのsso-sessionとprofileを手で書く方法
ウィザードが書き出す内容は、テキストエディタで直接書いても同じです。SDK・ツール共通のリファレンスでは、sso_region・sso_start_url・sso_registration_scopesはsso-session側、sso_account_idとsso_role_nameはprofile側に置くと定めています。
[profile dev]
sso_session = my-sso
sso_account_id = 111122223333
sso_role_name = PowerUserAccess
region = ap-northeast-1
output = json
[profile prod]
sso_session = my-sso
sso_account_id = 444455556666
sso_role_name = ReadOnlyAccess
region = ap-northeast-1
[sso-session my-sso]
sso_region = ap-northeast-1
sso_start_url = https://my-sso-portal.awsapps.com/start
sso_registration_scopes = sso:account:access
sso_role_nameに入れるのは権限セットの名前で、ロールのARNではありません。同リファレンスは、refresh tokenを受け取るには最低でもsso:account:accessのスコープが要ると明記しています。手書きでこの行を省いた場合、2.38.5のソースではPKCE認可はsso:account:accessを補って登録しますが、デバイスコード認可はスコープなしで登録します。--use-device-codeを使う端末ほど1時間で更新が止まりやすいので、行は必ず書いてください。書き終えたらaws configure list-profilesで、profile名が一覧に出るかを確かめます。
レガシー形式の見分け方と推奨形式への移行手順
セッション名を空欄にしてウィザードを進めると、profileの中にsso_start_urlとsso_regionを直接持つレガシー形式になります。公式は、この形式ではセッションが8時間固定で自動更新されず、期限が来ると新しい認証情報を取りに行くコードがすべて失敗すると注意しています。
移行は、[sso-session]セクションを1つ新設し、各profileからsso_start_urlとsso_regionを消してsso_session = my-ssoに置き換えるだけです。書き換えたらaws sso login --profile devを打ち直し、新しいトークンをキャッシュさせます。旧形式のprofileが1つでも残っていると、そのprofileだけ8時間で切れ続けるので、grep -n sso_start_url ~/.aws/configで[sso-session]の外にある行を洗い出してください。
aws sso loginの実行とPKCE・デバイスコード認可の切り替え
設定ができたら、profileを指定してコマンドを打ちます。既定のブラウザが開き、ポータルでの承認が終わると認証情報がキャッシュされます。
$ aws sso login --profile dev
$ aws sts get-caller-identity --profile dev
# 毎回の--profileを省くなら環境変数で固定する
$ export AWS_PROFILE=dev
$ aws s3 ls
コマンドリファレンス（2026年10月時点で2.38.5）が挙げる専用オプションは--no-browser、--use-device-code、--redirect-port、--sso-sessionの4つです。profileを指定せず、defaultも無い状態で他のコマンドを打つと、2.38.5はUnable to locate credentials. You can configure credentials by running "aws login".と返します。aws loginを勧める文言ですが、Identity Centerを使う環境ならprofileの指定漏れを先に疑ってください。
CLI 2.22.0以降のPKCE既定化とブラウザが開かないときの対処
公式ガイドによると、CLI 2.22.0からはProof Key for Code Exchange（PKCE）による認可が既定です。表示されるURLはhttps://oidc.ap-northeast-1.amazonaws.com/authorizeのような形式で始まり、サインインしている端末と同じ端末のブラウザで開く必要があります。ブラウザが自動で開かないときは、ターミナルに出たこのURLを同じ端末で手動で開いてください。
PKCEでは、ブラウザからの戻り先としてCLIが手元にコールバック用のポートを開きます。2.37.2で追加された--redirect-portはこのポートを固定するもので、省略時は空いているポートがランダムに選ばれます。社内のセキュリティ製品がランダムなポートの待ち受けを止める環境では、許可済みのポート番号を指定すると通る場合があります。2.38.2からは、このコールバックは全インターフェースでなく127.0.0.1だけで待ち受ける実装に変わりました。
SSH・コンテナでのuse-device-codeとno-browserの併用条件
ブラウザの無い踏み台サーバーや、ブラウザと別の名前空間で動くコンテナでは、PKCEのコールバックが手元に戻りません。この場合は--use-device-codeを付け、2.22.0より前の既定だったデバイスコード認可に切り替えます。表示されたURLをブラウザのある別のPCで開き、ターミナルに出たコードを入力する流れで、公式もこの方式は別の端末で開いてよいと説明しています。
$ aws sso login --profile dev --use-device-code --no-browser
Browser will not be automatically opened.
Please visit the following URL:
...
Then enter the code:
...
--no-browserはURLの自動オープンだけを止めるオプションで、上の2行目以降はCLI 2.38.5のソースにある表示文言です。ただしデバイスコードは、画面共有やチャットで他人に渡るとその人の端末で承認できてしまいます。受け渡しは本人の端末間に限る運用を決めておいてください。
WSL2でWindows側のブラウザを開くBROWSER環境変数の設定
WSL2のUbuntuでaws sso loginを打つと、Linux側にブラウザが無いためURLが開かずに止まることがあります。AWS CLIはPythonのwebbrowserモジュールでURLを開く実装（2.38.5のsso/utils.py）で、このモジュールは環境変数BROWSERに書いたプログラムを優先して使います。Windows側のブラウザの実行ファイルを指定すれば、ホストのブラウザが自動で開きます。
# ~/.bashrc に追記（Chromeの既定のインストール先の例）
export BROWSER='/mnt/c/Program Files/Google/Chrome/Application/chrome.exe'
ブラウザは開いたのに承認後の画面でCLIが待ち続ける場合は、Windows側からWSL2のコールバックのポートへ届いていません。その環境では--use-device-codeに切り替えるほうが早く片付きます。
複数アカウントでsso-sessionを共有しprofileだけ切り替える運用
先のconfig例のように、devとprodが同じsso-sessionを参照していれば、ログインは1回で済みます。aws sso login --sso-session my-ssoでセッション単位にサインインし、あとは--profileかAWS_PROFILEでアカウントを切り替える形です。リファレンスは、1つのsso-sessionで同時に有効なログインは1つだけで、profileを増やしても別の利用者を同じsso-sessionで並行して認証させることはできないと明記しています。1台の端末で2人分の権限を使い分けるなら、sso-sessionを分けてください。
本番アカウントには読み取り専用の権限セットだけを割り当てたprofileを用意し、変更作業のときだけ別のprofileを使う分け方が事故を減らします。権限セットの切り方そのものはAWS IAM Identity Centerの権限セット設計とCLI認証、ポリシーの書き方はAWS IAMのユーザー・ロール・ポリシーの違いで整理しています。
アクセスポータル8時間と権限セット1〜12時間の期限が効く仕組み
「朝ログインしたのに昼過ぎに切れた」「打ち直しても期限が変わらない」ときは、アクセスポータルと権限セットの期限を分けて確認します。
アクセストークンが1時間ごとに更新されるsso-session形式の流れ
認証情報の解決手順を説明した公式ページによると、aws sso loginを打つとIdentity Centerからアクセストークンとrefresh tokenを受け取り、~/.aws/sso/cacheのJSONに書き込みます。アクセストークンの有効期間は1時間で、切れるとSDKがrefresh tokenで新しいものを取り直します。この再取得は、アクセスポータルのセッションが生きている間だけ成功します。
見落としやすいのは、有効なセッションが残っている状態でaws sso loginを打つと、既存のセッションが再利用され、期限もその既存セッションに従う点です。終業前に打ち直しても延長にはなりません。延ばしたいならaws sso logoutで一度キャッシュを消し、新しいセッションとしてサインインし直します。
ポータル期限と権限セット期限の組み合わせで最大32時間になる例
アクセスポータル側は既定8時間で、15分から90日（129,600分）の範囲で管理者が変えられます。権限セット側は作成時に1時間、最大12時間で、CLIが実際にAWSのAPIを呼ぶときの認証情報の寿命を決めます。
| 期限の種類 | 既定値 | 設定範囲 | 切れたときの症状 |
|---|---|---|---|
| アクセスポータル | 8時間 | 15分〜90日 | 新しい認証情報を取れない |
| 権限セット | 1時間 | 1〜12時間 | 更新できなければ以後のAPI呼び出しが失敗 |
| レガシー形式 | 8時間固定 | 変更不可 | 自動更新されず失敗 |
公式の注意事項には、ポータル20時間・権限セット12時間の設定で、ポータルが切れる直前に権限セットを更新すると、CLIのセッションは20＋12の最大32時間続くという例が載っています。期限を長くするほど、退職者や端末紛失のときに残る時間も伸びます。長時間の作業が必要なら、ポータル側を延ばす前に処理をAWS内のロールへ移してください。
AD ConnectorやSAML IdPのセッション長が上限を縮める条件
Identity Center側で延ばしても、アイデンティティソースが先に切れることがあります。AWS Managed Microsoft ADはKerberosチケットの最大有効期間が10時間固定で、ポータルのセッションは設定値と10時間の短いほうになります（AD Connectorも既定10時間）。外部のSAML IdPでは、アサーションにSessionNotOnOrAfterが含まれていればIdPのセッション長との短いほうが採用されます。「設定を延ばしたのに変わらない」ときは、IdP側の属性を確認します。IdP連携の方式の違いはシングルサインオンの4つの実現方式とIDトークン検証にまとめています。
sso login後にSDK・Docker・Claude Codeへ認証情報を渡す手順
多くのSDKはconfigのsso-sessionを直接読めるため、AWS_PROFILEを指定するだけで動きます。困るのは、sso-sessionを読めないツールやコンテナ、独自の更新処理を持つツールへ渡すときです。
export-credentialsによる環境変数出力と非対応ツールへの橋渡し
aws configure export-credentialsは、sso loginで得た一時認証情報を指定の形式で書き出します。2.38.5の形式はprocess（既定）、env、env-no-export、powershell、windows-cmd、fishの6種類で、fishは2.33.8で加わりました。
# bash／zshで現在のシェルに一時認証情報を読み込む
$ eval "$(aws configure export-credentials --profile dev --format env)"
# PowerShellの場合
PS> aws configure export-credentials --profile dev --format powershell | Invoke-Expression
# sso-session非対応のツールにはcredential_processで橋渡しする
[profile dev-process]
credential_process = aws configure export-credentials --profile dev --format process
region = ap-northeast-1
環境変数へ書き出した認証情報は、権限セットの期限で切れても更新されません。Dockerコンテナへ-eで渡すのは数十分で終わる検証に限り、長く動かすツールにはcredential_processを使います。対応ツールは認証情報の取得時や有効期限前の更新時にこのコマンドを実行します。SSOセッション自体が切れた場合は、再ログインが必要です。
Claude CodeをBedrockで使うときのawsAuthRefresh設定
Amazon Bedrock経由でClaude Codeを使い、ポータルの期限切れなどによってAWS認証情報を取得・更新できなくなると、API Error: Could not load AWS credentialsで始まるエラーが出ます。Claude Codeのエラー一覧は、「·」の後ろに期限切れのSSOセッションなど具体の原因が続くと説明し、対処としてaws sso login --profile myprofileを打ってから再試行するよう案内しています。
毎回手で打たずに済ませるなら、Bedrockの設定ページにあるawsAuthRefreshを設定ファイルに書きます。認証情報の期限切れを検知したときだけ指定のコマンドを実行し、更新後に要求をやり直す設定です。
{
"awsAuthRefresh": "aws sso login --profile myprofile",
"env": {
"AWS_PROFILE": "myprofile"
}
}
同ページによると、Claude Codeは実行前にSTSのGetCallerIdentityで本当に切れているかを確かめ、まだ使えるならコマンドを飛ばします。社内VPNやTLS検査のプロキシがSSOのブラウザの流れを途中で切る環境では、サインインのタブが繰り返し開くことがあり、その場合はawsAuthRefreshを外して、起動前に手でaws sso loginを打つよう求めています。サブスクリプションやAPIキーでの認証と切り替える手順はClaude Codeのログイン方法で扱っています。
Java SDK 1.xとRust SDKでsso-session形式が使えない箇所と回避策
SDK・ツール共通リファレンスの対応表では、AWS SDK for Java 1.xがIdentity Centerの認証情報プロバイダに非対応、SDK for Rustはレガシー形式のみの部分対応です。Java 1.x系の業務アプリにはcredential_processを挟み、恒久的にはJava 2.xへ移します。公式の注意事項が挙げるセッション管理の最低版はPython（boto3）1.26.10、Java 2.18.13、JavaScript v3.210.0などで、これより古い依存ではsso-session形式にしても更新が効きません。
aws sso loginのエラー文言から原因を切り分ける手順
sso loginの前後で認証エラーが出たら、権限を疑う前に文言を読みます。文言には形式（sso-sessionかレガシーか）と、止まっている段階がそのまま出ています。
CLI 2.38.5で実測したエラー文言と原因の対応表
次の表は、隔離したconfigと~/.aws/sso/cacheを用意し、AWS CLI 2.38.5で状態を1つずつ作ってaws sts get-caller-identityを打ったときの文言です（2026年10月23日）。表には文言の特徴的な部分だけを載せています。
| 文言に含まれる語 | 形式 | 状態 | 直し方 |
|---|---|---|---|
Token for my-sso does not exist |
sso-session | 未ログイン・logout後 | aws sso login |
Token for https://…/start does not exist |
レガシー | 未ログイン・logout後 | 形式を移行してログイン |
Token has expired and refresh failed |
sso-session | ポータルの期限切れ | aws sso login |
has expired or is otherwise invalid |
レガシー | 8時間経過 | 形式を移行してログイン |
The specified sso-session does not exist |
sso-session | sso_sessionの名前違い | セクション名と揃える |
Invalid start url provided |
両方 | start URLの誤り | ポータルでURLを確認 |
同じ期限切れでも、sso-session形式はError when retrieving token from sso: Token has expired and refresh failed、レガシー形式はThe SSO session associated with this profile has expired or is otherwise invalid.で始まる文になります。後者が出たら、ログインし直す前にそのprofileを推奨形式へ移すと、同じエラーが8時間ごとに出なくなります。なおaws configure listもトークンが無い状態では同じError loading SSO Tokenを先に出すため、未ログインのまま設定の確認に使うと紛らわしくなります。
get-caller-identityとconfigure listでの認証元の確認
ログイン後にアクセス拒否が出る場合は、認証元の取り違えに加え、権限セットの許可不足やポリシーによる拒否を確認します。公式のトラブルシューティングも、認証情報が想定外の場所から読まれている可能性を挙げ、aws configure listで確認するよう案内しています。
$ aws configure list --profile dev
$ aws sts get-caller-identity --profile dev
{
"UserId": "AROAEXAMPLEID:[email protected]",
"Account": "111122223333",
"Arn": "arn:aws:sts::111122223333:assumed-role/AWSReservedSSO_PowerUserAccess_0123456789abcdef/[email protected]"
}
ArnにAWSReservedSSO_で始まるロール名が出ていれば、Identity Centerの権限セット経由で解決できています。IAMユーザーのARNが返る場合、profileを指定せずに打ったのなら、環境変数AWS_ACCESS_KEY_IDかcredentialsファイルの長期キーが優先されています。--profileはコマンドラインの指定として環境変数より優先されるので、付けたうえでIAMユーザーが返るなら、そのprofile自体に長期キーが書かれていないかを確かめます。シェルの初期化ファイルに残ったexportを消し、新しいターミナルで確かめ直してください。返り値の読み方とエラー別の直し方はaws sts get-caller-identityの使い方で詳しく扱っています。
aws sso logoutとキャッシュ削除で再ログインをやり直す手順
start URLやsso-session名を変えた直後は、キャッシュと設定が食い違ってエラーが続くことがあります。その場合は次の順でやり直します。
aws sso logoutでキャッシュ済みのトークンと一時認証情報を削除する（リファレンスの説明どおり全profileが対象）configのsso-session名とprofileのsso_sessionが一致しているかを目で確認するaws sso login --sso-session my-ssoで新しいセッションを張るaws sts get-caller-identity --profile devで意図したアカウントとロールが返るかを確かめる
2.38.5で試すと、logoutの後は~/.aws/sso/cacheのJSONがsso-session分もレガシー分も消えていました。端末の時刻が数分以上ずれていると、正しい認証情報でも署名の検証で拒否されます。仮想マシンのスリープ復帰直後にだけ失敗するなら、時刻同期を先に疑ってください。
aws sso loginを採用しない場面と組織のID基盤から見た判断基準
aws sso loginは、人が自分の端末で対話的に作業するためのコマンドです。この前提から外れる場面では使いません。
CI/CDや夜間バッチでsso loginを使わずOIDCとロールに寄せる条件
CI／CDでaws sso loginは採用しません。PKCEもデバイスコードも人がブラウザで承認する操作が必須で、無人のパイプラインでは完了しないからです。GitHub ActionsならOIDCでIAMロールを引き受け（設定はconfigure-aws-credentialsの使い方）、AWS内で動く処理はタスクロールやインスタンスプロファイルを使います。
開発者の端末で夜間バッチを回す運用も見送りです。ポータルのセッションが切れた瞬間に、新しい認証情報の取得が失敗します。数時間を超えて動く処理はEC2やECSのタスクへ移してIAMロールで実行し、手元の端末はそれを起動するまでに留めてください（Lambdaは1回の実行が最大15分です）。Identity Centerを入れていない単一アカウントの小さなチームなら、aws loginコマンドとsso login・アクセスキーとの使い分けで紹介したaws loginのほうが導入の手間が少なく済みます。
社内IdPとIdentity Centerをつなぐ設計を先に固めるべき組織
複数のAWSアカウントで入退社に伴う権限変更を一元管理する組織では、aws sso loginの設定を配る前に、社内のIdP（Microsoft Entra IDやOktaなど）とIdentity Centerの連携を固めるべきです。IdP側の退職処理に加え、Identity Centerへの無効化の反映と既存セッションの終了を確認しないと、ポータルのセッションを90日に延ばした端末が退職後も残ります。
開発者ごとにconfigを手作業で配ると、権限セット名やアカウントIDがばらばらになります。sso-sessionのひな形を1つ決めて配布し、期限の長さはIdP側と揃えてください。社員IDの管理からSSO連携までを見直す段階なら、認証基盤・ID管理システム開発として設計から引き受けています。
よくある質問
aws sso loginの保存先、再ログイン、プロファイル確認、有効期限について、公式ドキュメントの記述に沿って答えます。
aws sso loginの認証情報はどこに保存されますか？
アクセストークンとrefresh tokenは~/.aws/sso/cache配下のJSONファイルに保存されます。ファイル名は、推奨形式ではsso-sessionの名前を、レガシー形式ではsso_start_urlをSHA-1でハッシュした値です。トークンはセッション期限まで有効なので、共有端末で同じOSユーザーを使い回す運用は避け、作業後はaws sso logoutで削除してください。
aws sso loginは毎回打たないといけないのですか？
アクセスポータルのセッションが有効な間は不要です。sso-session形式なら、アクセストークンと権限セットの認証情報の取り直しをCLIとSDKが自動で行います。ポータルの期限（既定8時間）が切れたら打ち直してください。頻繁に打たされるなら、レガシー形式が残っていないかを先に確認します。
aws sso loginとaws loginはどう違いますか？
aws sso loginはIAM Identity Centerの利用者向けで、アクセスポータル経由で権限セットの一時認証情報を得ます。aws loginはCLI 2.32.0で追加されたコマンドで、マネジメントコンソールのサインイン（ルート・IAMユーザー・IAMフェデレーション）をそのままCLIの認証に使うものです。Identity Centerを使っている組織ならaws sso login、使っていない単一アカウントならaws loginという住み分けになります。
aws sso loginで使えるプロファイルの一覧はどう確認しますか？
aws configure list-profilesで、configとcredentialsにあるprofile名が1行ずつ出ます。sso-session形式のprofileもここに並ぶので、目的の名前をaws sso login --profileに渡してください。一覧に出ないときは、[profile 名前]の書き方か、AWS_CONFIG_FILEで別のファイルを読ませていないかを確認します。
sso loginの有効期限を延ばすにはどこを変えますか？
延ばしたい対象によって設定箇所が違います。ポータルへのサインインの長さはIdentity Centerコンソールの「設定」から「認証」タブのセッション期間で、15分〜90日の範囲です。APIを呼ぶ認証情報の寿命は権限セットの「セッション期間」で、1〜12時間の範囲になります。ポータル側の変更は新しいセッションにだけ効くので、変更後はaws sso logoutしてから再ログインしてください。
