aws sso loginは、IAM Identity Centerのアクセスポータルにブラウザでサインインし、手元のAWS CLIとSDKに一時認証情報を渡すコマンドです。事前にconfigへsso-sessionを書く必要があり、旧形式のままだと8時間で切れて自動更新も効きません。sso-session設定の書き方、CLI 2.22.0で既定になったPKCE認可とデバイスコード認可の使い分け、2つの期限の関係、SDKやDockerへの受け渡し、期限切れエラーの切り分けまでを扱います。
まとめ：aws sso loginで押さえるsso-session設定と2種類の期限
設定は[sso-session]セクションを持つ推奨形式で書き、sso_registration_scopes = sso:account:accessまで明記します。このスコープが無いとrefresh tokenが返らず、1時間ごとのアクセストークン更新が働きません。旧形式は8時間固定で更新されないため、既存の設定は移行対象です。
期限は2本立てです。アクセスポータルのセッション（既定8時間、15分〜90日で変更可）と、権限セットのセッション（既定1時間、最大12時間）が別々に効きます。aws sso loginを打ち直してもポータル側の期限は延びません。ブラウザでの本人確認が前提のコマンドなので、CI／CDや無人のバッチでは採用せず、OIDCやIAMロールに寄せてください。
aws sso login前のconfigure ssoでのsso-session設定手順
aws sso loginは、どのポータルへ、どのアカウントとロールで入るかをconfigから読み取ります。先にこの設定を作る工程が必要で、ウィザードで作ってから手で整える流れが確実です。AWS CLI自体がv1のままなら、AWS CLI v2の設定とv1サポート終了への移行手順で先に入れ替えてください。
aws configure ssoの対話設定とstart URL・SSOリージョンの確認
aws configure ssoを実行すると、セッション名、start URL、SSOリージョン、登録スコープの4つが順番に表示され、それぞれの値を入力する対話形式です。公式の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 [None]: sso:account:access
ブラウザで認証を終えると、使えるアカウントとロールの一覧が出ます。候補が1つしかなければCLIが自動で選び、質問を飛ばす仕様です。最後に既定リージョン、出力形式、プロファイル名を入れて完了します。SSOリージョンはIdentity Centerを有効化したリージョンで、既定リージョンと違っていて構いません。
生成された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のスコープが要ると明記しています。ウィザードで登録スコープを空欄のまま進めた設定は、ここを追記してください。
レガシー形式が8時間固定で自動更新されない理由と推奨形式への移行手順
セッション名を空欄にしてウィザードを進めると、profileの中にsso_start_urlとsso_regionを直接持つレガシー形式になります。公式は、この形式ではセッションが8時間固定で自動更新されず、期限が来ると新しい認証情報を取りに行くコードがすべて失敗すると注意しています。このレガシー形式で暗黙的に指定される登録スコープも、sso:account:accessだけに限られる仕様です。
移行は、[sso-session]セクションを1つ新設し、各profileからsso_start_urlとsso_regionを消してsso_session = my-ssoに置き換えるだけです。書き換えたら一度aws sso login --profile devを打ち直し、新しいトークンをキャッシュさせます。旧形式のprofileが1つでも残っていると、そのprofileだけ8時間で切れる状態が続くので、grep sso_start_url ~/.aws/configで残りを洗い出してください。
aws sso loginの実行とPKCE・デバイスコード認可の切り替え手順
設定ができたら、あとはコマンドを打つだけです。既定のブラウザが開き、ポータルでの承認が終わると認証情報がキャッシュされます。
$ aws sso login --profile dev
SSO authorization page has automatically been opened in your default browser.
Follow the instructions in the browser to complete this authorization request.
Successfully logged into Start URL: https://my-sso-portal.awsapps.com/start
$ aws sts get-caller-identity --profile dev
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を同じ端末で手動で開いてください。
コマンドリファレンス（2026年9月時点で2.37系）には、--redirect-portというオプションもあります。PKCEのコールバックを受けるローカルポートを固定するもので、省略時は空いているポートがランダムに選ばれる。社内のセキュリティ製品がランダムなポートの待ち受けを止める環境では、許可済みのポート番号をこのオプションで指定すると通る場合があります。
SSH・WSL・コンテナでのuse-device-codeとno-browser併用条件
ブラウザの無い踏み台サーバーや、ブラウザと別の名前空間で動くコンテナでは、PKCEが使えません。この場合は--use-device-codeを付け、2.22.0より前の既定だったデバイスコード認可に切り替えます。表示されたURLを手元のPCで開き、ターミナルに出たQCFK-N451形式のコードを入力する流れで、公式もこの方式は別端末で開いてよいと説明しています。
$ aws sso login --profile dev --use-device-code --no-browser
--no-browserはURLの自動オープンだけを止めるオプションです。SSH越しにブラウザ起動を試みてエラーを出すWSLやリモート開発環境では、2つを併用すると表示が落ち着きます。ただしデバイスコードは画面共有やチャット経由で他人に渡ると、その人の端末で承認できてしまう。受け渡しは本人の端末間に限る運用を決めておいてください。
複数アカウントでsso-sessionを共有しprofileだけ切り替える運用
先のconfig例のように、devとprodが同じsso-sessionを参照していれば、ログインは1回で済みます。aws sso login --sso-session my-ssoでセッション単位にサインインし、あとは--profileか環境変数AWS_PROFILEでアカウントを切り替える形です。--sso-sessionはレガシー形式では使えません。
本番アカウントには読み取り専用の権限セットだけを割り当てたprofileを用意し、変更作業のときだけ別のprofileを使う分け方が事故を減らします。権限セットの切り方そのものはIAM Identity Centerの権限セット設計とCLI認証、ポリシーの書き方はAWS IAMのユーザー・ロール・ポリシーの違いで整理しています。
アクセスポータル8時間と権限セット1〜12時間の期限が効く仕組み
「朝ログインしたのに昼過ぎに切れた」「打ち直しても期限が変わらない」という相談の大半は、2つの期限を1つだと思っていることが原因です。
アクセストークンが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時間 | 実行中の処理が権限を失う |
| レガシー形式 | 8時間固定 | 変更不可 | 自動更新されず即失敗 |
公式の注意事項には、ポータル20時間・権限セット12時間の設定で、ポータルが切れる直前に権限セットを更新すると、CLIのセッションは20＋12の最大32時間続くという例が載っています。期限を長く設定するほど、退職者や端末紛失時に残る時間も伸びる。長時間の作業が必要なら、ポータル側を延ばす前に処理をAWS内のロールへ移すほうを検討してください。
AD ConnectorやSAML IdPのセッション長が上限を縮める条件
Identity Center側で12時間に設定しても、アイデンティティソースが先に切れることがあります。AWS Managed Microsoft ADではKerberosチケットの最大有効期間が10時間に固定されており、ポータルのセッションは設定値と10時間の短いほうになる。AD Connectorも既定は10時間です。
外部のSAML IdPを使う場合は、アサーションにSessionNotOnOrAfterが含まれているかで挙動が分かれます。含まれていればIdPのセッション長との短いほうが採用され、含まれていなければIdentity Centerの設定がそのまま効く。「設定を延ばしたのに変わらない」ときは、IdP側の属性を確認します。IdP連携の方式の違いはシングルサインオンの4つの実現方式とIDトークン検証にまとめています。
sso login後にSDK・Docker・既存ツールへ認証情報を渡す実装手順
多くのSDKはconfigのsso-sessionを直接読めるため、AWS_PROFILEを指定するだけで動きます。困るのは、sso-sessionを読めないツールやコンテナへ渡すときです。
export-credentialsによる環境変数出力と非対応ツールへの認証情報の橋渡し
aws configure export-credentialsは、sso loginで得た一時認証情報を指定の形式で書き出します。形式はprocess（既定）、env、env-no-export、powershell、windows-cmd、fishの6種類です。
# 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を使えば、ツールが認証情報を要求するたびにCLIが最新の値を返します。
SSO非対応のJava SDK 1.x・Rust SDKで詰まる箇所と回避策
SDK・ツール共通リファレンスの対応表では、AWS SDK for Java 1.xがIdentity Centerの認証情報プロバイダに非対応、SDK for Rustはレガシー形式のみの部分対応です。Java 1.x系の古い業務アプリは、sso-session形式のプロファイルを指定しても、そこから認証情報を解決できません。
回避策は2つです。短期的には前の見出しのcredential_processを挟み、恒久的にはJava 2.xへ移行します。公式はセッション管理に対応する最低版として、Python（boto3）1.26.10、Java 2.18.13、JavaScript v3.210.0などを挙げています。依存ライブラリの版がこれより古ければ、sso-session形式にしても更新が効きません。
ログイン後の期限切れ・プロファイル不一致エラーを切り分ける確認手順
sso loginの直後にアクセス拒否や認証失敗が出たら、権限を疑う前に「どの認証情報が使われているか」を確かめます。
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が返るなら、credentialsファイルの長期キーか、環境変数AWS_ACCESS_KEY_IDが優先されている状態です。シェルの初期化ファイルに残ったexportを消し、新しいターミナルで確かめ直してください。--debugを付けると、どの経路を順に試したかまで出力されます。
キャッシュ削除とaws sso logoutで再ログインをやり直す手順
期限切れのエラーは、多くの場合aws sso loginの打ち直しで解消します。直らないときは、start URLやsso-session名を変えた直後で、キャッシュと設定が食い違っている状態を疑います。
aws sso logoutでキャッシュ済みの認証情報を削除する（公式の出力は「Successfully signed out of all SSO profiles.」で、全profileが対象）configのsso-session名とprofileのsso_sessionが一致しているかを目で確認するaws sso login --sso-session my-ssoで新しいセッションを張るaws sts get-caller-identityで意図したアカウントとロールが返るかを確かめる
端末の時刻が数分以上ずれていると、正しい認証情報でも署名の検証で拒否されます。仮想マシンのスリープ復帰直後にだけ失敗するなら、時刻同期を先に疑ってください。
aws sso loginを採用しない場面と組織のID基盤から見た判断基準
aws sso loginは、人が手元の端末で対話的に作業するためのコマンドです。この前提から外れる場面では使いません。
CI/CDや夜間バッチでsso loginを使わずOIDCとロールに寄せる条件
結論から書くと、CI／CDでaws sso loginは採用しません。PKCEもデバイスコードも、人がブラウザで承認する操作が必須で、無人のパイプラインでは完了しないからです。GitHub ActionsならOIDCでIAMロールを引き受け、AWS内で動く処理はタスクロールやインスタンスプロファイルを使います。
開発者の端末で夜間バッチを回す運用も見送りです。ポータルのセッションが切れた瞬間に、新しいクライアントの作成が失敗します。数時間を超える処理はEC2やLambdaへ移し、手元の端末はそれを起動するまでに留めてください。Identity Centerを入れていない単一アカウントの小さなチームなら、aws loginコマンドとsso login・アクセスキーとの使い分けで紹介したaws loginのほうが導入の手間が少なく済みます。
社内IdPとIdentity Centerをつなぐ設計を先に固めるべき組織
アカウントが3つを超え、人の出入りが毎月発生する組織では、aws sso loginの設定を配る前に、社内のIdP（Microsoft Entra IDやOktaなど）とIdentity Centerの連携を固めるべきです。IdP側で退職処理をすればAWSへの入口も自動で閉じる状態を作らないと、ポータルのセッションを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をもとに決まる。トークンはセッション期限まで有効なので、共有端末で同じ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を実行できますか？
できます。--use-device-codeを付けるとデバイスコード認可になり、表示されたURLを別の端末のブラウザで開いてコードを入力すれば承認が完了します。CLI 2.22.0以降の既定であるPKCE認可は同じ端末のブラウザが必要なため、踏み台サーバーやコンテナではこのオプションが前提です。自動でブラウザを開こうとしてエラーになる環境では--no-browserも併用してください。
sso loginの有効期限を延ばすにはどこを変えますか？
延ばしたい対象によって設定箇所が違います。ポータルへのサインインの長さはIdentity Centerコンソールの「設定」から「認証」タブのセッション期間で、15分〜90日の範囲です。APIを呼ぶ認証情報の寿命は権限セットの「セッション期間」で、1〜12時間の範囲になります。ポータル側の変更は新しいセッションにだけ効くので、変更後はaws sso logoutしてから再ログインしてください。
関連記事
- AWS IAM Identity Centerとは？権限セット設計とCLI認証・IAMとの使い分けを実装者目線で解説：sso loginの前提になる権限セットとアイデンティティソースの設計です。
- aws loginコマンドの実行手順とsso login・アクセスキーとの使い分け：Identity Centerを使わない環境での認証方式を比較しています。
- AWS CLIの導入と運用｜v2の設定・SSO認証・v1サポート終了への移行手順：CLI本体の導入とv2への移行を扱っています。
- AWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティス：権限セットに入れるポリシーの考え方が分かります。
- シングルサインオン（SSO）とは？4つの実現方式とIDトークン検証・IdP選定：社内IdPとIdentity Centerをつなぐ前提知識です。
