2026.10.18 AWS

Cognito SAML連携の手順：Entra IDでSSOを組む設定と属性マッピング

Q: IdP起点（IdP-initiated）のSSOにも対応していますか？

対応しています。ProviderDetailsで IDPInit を true にすると、Entra IDのマイアプリなどから起動したSSOを受け付けます。ただし、IdP起点を有効にしたIdPを割り当てたアプリクライアントには他のSAML IdPしか追加できず、ローカルユーザーやOIDC、ソーシャルIdPとは併用できません。併用が必要なら、IdP起点用のアプリクライアントを別に作ってください。

Q: SAMLでサインインしたユーザーのログアウトはどう扱われますか？

IDPSignout を true にすると、Cognitoのログアウトエンドポイントを呼んだときにIdPへ署名付きのログアウトリクエストを送り、IdPのセッションも終えるシングルログアウトになります。IdPからの応答はHTTP POSTで saml2/logout へ返す必要があり、GETのバインディングは受け付けません。無効のままだとCognitoのセッションだけが消え、IdPのセッションは残ります。

Amazon CognitoのユーザープールはSAML 2.0のサービスプロバイダー（SP）として動き、Microsoft Entra IDなどの外部IdPでサインインした社員を、そのままアプリへ通せます。この記事では、Entra ID側のエンタープライズアプリの設定、AWS CLIでのSAML IdP登録と属性マッピング、メールドメインによるIdPの振り分け、失敗時の切り分けまでを、2026年10月時点の公式ドキュメントに沿って手順で示します。OIDCで連携する場合との違いと、Cognitoを挟まない方がよい場面も最後に整理しました。

まとめ：Cognito SAML連携はNameIDの固定と属性マッピングを先に決める

Cognito SAML連携の作業は、IdPに「SPエンティティID」と「ACS URL」の2値を登録し、Cognitoに「メタデータURL」と「属性マッピング」を登録する往復でできています。設定画面の操作量は多くありません。

つまずく箇所は設計の側にあります。CognitoはNameIDの値でユーザーを識別するため、Entra IDの既定であるUPN（ユーザープリンシパル名）のままだと、改姓やドメイン変更でUPNが変わった時点で別人として新しいユーザーが作られます。NameIDはオブジェクトIDのような変わらない値に変え、必須属性のマッピングとアプリクライアントの書き込み権限を揃えてから本番に出してください。IdPが1つで今後も増えないなら、Cognitoを挟まずアプリをEntra IDへ直接つなぐ方が構成は軽くなります。

CognitoがSAMLのSPとして受け取る値とOIDC連携との違いを確認する

SAML連携には、ユーザープール・アプリクライアント・ユーザープールドメインの3つが先に必要です。まだ無い場合はCognitoで認証基盤を実装する手順：ユーザープール構築からJWT検証までで土台を作ってから進めてください。IdPとSPの関係やアサーションの仕組みはSAMLとは？認証フロー・IdP／SPの仕組みとOAuth・OIDCとの使い分けで解説しています。

IdPへ登録するSPエンティティIDとACS URLとアサーションの必須要素

IdP側に登録する値は、CognitoのSAML IdPに関する公式の注意事項で決まっています。プールIDとドメインが分かれば、IdPの管理者に渡す値はそろいます。

項目	Cognitoが求める値
SPエンティティID	固定の接頭辞＋プールID
ACS URL（応答URL）	プールのドメイン＋固定パス
バインディング	HTTP POST
NameID	変わらない値（Persistent形式を推奨）

具体的な形は、SPエンティティIDがurn:amazon:cognito:sp:ap-northeast-1_EXAMPLE、ACS URLがhttps://プールのドメイン/saml2/idpresponseです。アサーションには、NameID、SPエンティティIDを値に持つAudienceRestriction、ACS URLを指すRecipientが必要です。SP起点ではInResponseToが元のリクエストIDと一致していなければならず、逆にIdP起点ではInResponseToを含めてはいけません。同じアサーションIDの再送（リプレイ）も拒否されます。

SAMLとOIDCのどちらでEntra IDなど外部IdPをつなぐかの比較観点

Entra IDはSAMLとOIDCの両方に対応しているため、どちらで登録するかを先に決めます。違いはOIDC IdPの公式ガイドと並べると明確です。

観点	SAML	OIDC
IdPに登録する戻り先	/saml2/idpresponse	/oauth2/idpresponse
Cognitoに渡す情報	メタデータのURLかXML	クライアントIDとシークレット
クライアント認証	署名証明書で信頼	client_secret_postのみ
ユーザー名の元	NameID	sub
鍵の更新への追随	メタデータURLで最大6時間	jwks_uriから取得

Entra IDをOIDCで登録するときの発行者URLはhttps://login.microsoftonline.com/テナントID/v2.0の形式です。判断の目安は単純で、取引先や既存SaaSの運用がSAMLで揃っているならSAML、新しくアプリ登録をするだけならOIDCの方が設定項目は少なく済みます。

SAML連携ユーザーは月50MAUの無料枠を超えると1人0.015ドルかかる

Cognitoの料金ページでは、SAMLまたはOIDCでサインインしたユーザーは、アカウント（またはAWS Organizations）あたり月50MAUの無料枠を超えた分が1MAUあたり0.015ドルとされています（2026年10月時点）。単価はLite・Essentials・Plusのどのプランでも同じで、連携機能自体は全プランで使えます。社員5,000人が毎月サインインするなら、(5,000−50)×0.015＝74.25ドルが目安です。

見落としやすいのは、IdPを削除して作り直すとSAMLユーザーが新しいプロファイルとして作られる点です。公式ガイドも、IdP設定を変えた月はアクティブユーザーの重複で請求に影響しうると書いています。プロバイダー名は最初に決め、作り直さない前提で進めます。

Entra IDのエンタープライズアプリでCognito向けのSAML設定を作る手順

ここからはEntra ID側の作業です。Entra管理センターでクラウドアプリケーション管理者以上の権限を持つアカウントを使います。

識別子と応答URLにプールIDとidpresponseのURLを登録する手順

Entra管理センターのエンタープライズアプリケーションで、ギャラリー外の独自アプリを新規作成する
シングルサインオンの方式でSAMLを選び、基本的なSAML構成の識別子にurn:amazon:cognito:sp:ap-northeast-1_EXAMPLEを入れる
応答URLにhttps://auth.example.co.jp/saml2/idpresponseのようにプールのドメインのACS URLを入れる
SAML証明書の欄にある「アプリのフェデレーションメタデータURL」を控える
ユーザーとグループで、サインインを許可するユーザーまたはグループを割り当てる

カスタムドメインを使うなら、応答URLもそのドメインで登録します。後からドメインを変えるとIdP側の登録もやり直しになるため、本番ドメインで最初から作る方が手戻りの少ない方法です。メタデータはファイルのアップロードより、URLで渡す方が証明書の更新に自動で追随できます。

NameIDの既定値UPNをオブジェクトIDに変えてユーザーの重複を防ぐ

Microsoft LearnのSAMLクレームの説明のとおり、Entra IDは既定でユーザーのUPNをNameIDとして送ります。一方Cognitoは、NameIDが変わると新しいユーザーとみなす仕様です。改姓、部署統合によるドメイン変更、UPNの命名規則の見直しのどれかが起きると、同じ社員に2つ目のプロファイルができ、アプリ側のデータとの紐づけが切れます。

対策は、属性とクレームの画面で名前識別子の値をuser.objectidに変え、形式をPersistentにすることです。Cognitoのユーザー名は「プロバイダー名_NameID」となり、大文字小文字を区別しないプールでは全体が小文字になります。メールアドレスは別のクレームで送り、属性マッピングでemailに入れれば表示や通知に利用可能です。NameIDの形式が噛み合わずに失敗するときはSAML NameIDFormatとメタデータの不一致でSSOが失敗する原因の切り分けが参考になります。

AWS CLIでSAML IdPを登録し属性マッピングとアプリクライアントを設定する

Cognito側はコンソールの「ソーシャルプロバイダーと外部プロバイダー」からも追加できますが、ここでは再現しやすいAWS CLIの例を示します。

create-identity-providerでメタデータURLとクレームURIを渡す

CreateIdentityProviderのAPIリファレンスによると、SAMLのProviderDetailsに渡すキーはMetadataURL（またはMetadataFile）、IDPSignout、IDPInit、EncryptedResponses、RequestSigningAlgorithmです。まず次の内容でprovider-details.jsonを作ります。

{
  "MetadataURL": "https://login.microsoftonline.com/TENANT_ID/federationmetadata/2007-06/federationmetadata.xml?appid=APP_ID",
  "IDPSignout": "true",
  "RequestSigningAlgorithm": "rsa-sha256"
}

続けて、Entra IDが送るクレームのURIを属性マッピングに指定して登録します。

aws cognito-idp create-identity-provider \
  --user-pool-id ap-northeast-1_EXAMPLE \
  --provider-name EntraID \
  --provider-type SAML \
  --provider-details file://provider-details.json \
  --attribute-mapping 'email=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress,given_name=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname,family_name=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname'

# 読み込まれたSSOとSLOのURIを確かめる
aws cognito-idp describe-identity-provider \
  --user-pool-id ap-northeast-1_EXAMPLE \
  --provider-name EntraID

プロバイダー名は32文字以内で、認可リクエストのidentity_providerにそのまま使うため、短く変えない名前にします。Entra IDのクレームはURI形式の名前で届くので、マッピングの値もemailaddress単体ではなくURI全体で書く点に注意してください。

アプリクライアントに外部IdPを追加して認可エンドポイントから直接遷移させる

IdPを登録しただけでは、どのアプリからも使えません。アプリクライアントのSupportedIdentityProvidersにプロバイダー名を加えます。UpdateUserPoolClientは指定しなかった項目を既定値に戻すため、先に現在の設定を控え、既存の値もすべて渡してください。

# 現在の設定を控える（未指定の項目は既定値に戻るため）
aws cognito-idp describe-user-pool-client \
  --user-pool-id ap-northeast-1_EXAMPLE \
  --client-id 1example23456789 > client-before.json

aws cognito-idp update-user-pool-client \
  --user-pool-id ap-northeast-1_EXAMPLE \
  --client-id 1example23456789 \
  --supported-identity-providers COGNITO EntraID \
  --allowed-o-auth-flows-user-pool-client \
  --allowed-o-auth-flows code \
  --allowed-o-auth-scopes openid email profile \
  --callback-urls https://app.example.co.jp/callback

マネージドログインの画面を経ずにEntra IDのサインイン画面へ直行させるなら、認可エンドポイントにidentity_providerを付けます。社内ポータルのリンクに埋めておけば、利用者はCognitoの画面を見ずにサインインを終えられます。

https://auth.example.co.jp/oauth2/authorize?identity_provider=EntraID&response_type=code&client_id=1example23456789&redirect_uri=https%3A%2F%2Fapp.example.co.jp%2Fcallback&scope=openid+email

マネージドログインに外部IdPのボタンを並べる場合の見た目の調整は、AWS Cognito Hosted UI（マネージドログイン）のカスタマイズ・日本語化と実装手順で扱っています。

属性マッピングで詰まる必須属性・変更可能属性・書き込み権限の3条件

属性マッピングの公式ガイドが挙げる条件のうち、サインインの失敗に直結するのは次の3つです。

プールで必須にした属性（多くはemail）すべてに、IdPのクレームを割り当てている
マッピング先のカスタム属性を先にスキーマへ追加し、変更可能（Mutable）にしている
アプリクライアントの書き込み権限に、マッピングした属性がすべて含まれている

変更不可の属性にIdPから値が届くと、サインインは失敗します。書き込み権限が無い場合の挙動は、値を更新せず認証を続けると書く資料と、エラーになると書く資料があり、公式の記述が揃っていません。どちらでも不具合になるため、権限は必ず付けます。マッピングしたメールアドレスは未検証の扱いで、ワンタイムコードでの検証もできません。値の長さは2,048文字までです。

取引先ごとのIdP振り分けと既存のローカルユーザーとの紐づけを実装する

IdPが1つなら前章までで動きます。複数の会社の社員を受ける場合と、パスワード認証からSSOへ移行する場合は、もう一段の実装が必要です。

IdP識別子にメールドメインを登録して取引先ごとのIdPへ振り分ける

BtoB SaaSのように1つのアプリで複数の会社を受けるなら、会社ごとにSAML IdPを登録し、IdP識別子にその会社のメールドメインを入れます。識別子はプール全体で最大50個で、1つのIdPに複数のドメインを持たせる設定も可能です。マネージドログインはメールアドレスの入力を求め、ドメインが一致したIdPへ転送します。

注意点は2つあります。マネージドログインでこの入力欄を出すには、ブランディングエディタで「Domain search input」を有効にする設定が必要です。また、アプリクライアントに割り当てたSAML IdPのすべてに識別子を付けると、IdPを選ぶボタンは表示されなくなります。自前のログイン画面で振り分けるなら、認可リクエストにidp_identifier=example.co.jpを付ければ同じ転送ができます。

既存ユーザーをAdminLinkProviderForUserでSAMLと紐づける

パスワードでサインインしていた既存ユーザーをSSOへ移す場合、何もしないと初回のSAMLサインインで別のユーザーが作られ、権限やデータが引き継がれません。AdminLinkProviderForUserで、まだサインインしていないSAML側の識別子を既存ユーザーへ先に結びつけておきます。

aws cognito-idp admin-link-provider-for-user \
  --user-pool-id ap-northeast-1_EXAMPLE \
  --destination-user ProviderName=Cognito,ProviderAttributeValue=existing-user-01 \
  --source-user ProviderName=EntraID,ProviderAttributeName=Cognito_Subject,ProviderAttributeValue=00000000-0000-0000-0000-000000000000

Cognito_Subjectを指定すると、CognitoがアサーションのNameIDを読み取って照合します。1ユーザーに紐づけられる外部IDは5つまでです。公式リファレンスは、この操作で外部IDがローカルユーザーとしてサインインできるようになるため、信頼できるIdPと属性だけに使うよう警告しています。IdP側で利用者がメールアドレスを変えられる環境では、メールで紐づけると乗っ取りの経路になるため、NameIDで結ぶ方を選びます。

SAML連携が失敗するときの切り分けと署名証明書の更新を運用する

SAMLのエラーは画面に詳細が出にくいため、症状から確認箇所を絞ります。アサーションの中身は、ブラウザの開発者ツールでidpresponseへのPOST本文を見れば確かめられます。

サインイン失敗をアサーションの要素とCognito側の設定から切り分ける

症状	確認する箇所
IdPでの認証後にCognitoでエラー	AudienceとRecipientの値
同じ人が別ユーザーとして作られる	NameIDがUPNやメールのままか
必須属性のエラーで止まる	必須属性のクレームとマッピング
特定の氏名の人だけ失敗する	属性値の4バイト文字
IdP登録時にメタデータ取得エラー	メタデータURLのTLS証明書とポート

4バイト文字の制約は日本の利用者で起きやすい問題です。Cognitoは4バイトのUTF-8文字を属性値として受け付けないため、JIS第3・第4水準の異体字を含む氏名がそのまま送られると、その人だけサインインできません。公式ガイドは、Base64で符号化して送り、アプリ側で復号する方法を示しています。メタデータURLは443番か80番のポートでしか受け付けない点も、社内IdPを使う場合の確認項目です。

署名証明書の更新はメタデータURLの6時間キャッシュを前提に新旧を併記する

CognitoはメタデータURLから取得した内容を最大6時間キャッシュします。IdPで署名証明書を更新するときは、新旧両方の証明書をメタデータに載せた状態を6時間以上保ってから、新しい証明書での署名に切り替えます。メタデータに複数の証明書があれば、どれかに一致したアサーションを有効とする仕様なので、この併記期間が証明書の切り替えにおける安全域です。

メタデータをファイルで登録した場合は自動では追随しないため、更新のたびにupdate-identity-providerを流す必要があります。証明書の期限切れは全社員が同時にサインインできなくなる障害につながるため、有効期限を監視の対象に入れておきます。

Cognito SAML連携を採用する条件とCognitoを挟まない方がよい場面

ここまでの仕様を踏まえ、Cognito SAML連携を採るかどうかを条件で切り分けます。

複数の取引先IdPを1つのアプリで受けるならCognitoのSAML連携を選ぶ

Cognitoを挟む価値が大きいのは、IdPが2つ以上ある場合です。取引先ごとにEntra ID、Okta、Google Workspaceと異なるIdPを使っていても、アプリが受け取るのはCognitoが発行する同じ形式のJWTだけで、検証処理は1つで済みます。属性名の違いも、IdPごとの属性マッピングでCognito側の標準属性に揃えることが可能です。ローカルのパスワードユーザーとSSOユーザーが混在する会員基盤でも同じ利点があります。

社内IdPが1つだけの業務アプリはCognitoを挟まずEntra IDへ直接つなぐ

社員だけが使う業務アプリで、IdPがEntra IDの1つに決まっているなら、Cognitoは挟みません。アプリをEntra IDにOIDCで直接登録すれば、NameIDの設計も属性マッピングもIdP側の設定だけで済み、SAML連携ユーザーのMAU課金もかかりません。ALB配下の既存アプリなら、ALBとCognitoで認証を後付けする手順で扱うリスナールールの認証アクションで後付けする方法もあります。

採用の条件は、IdPが複数ある、将来増える見込みがある、ローカルユーザーと混在する、のどれかに当てはまることです。どれにも当てはまらなければ見送ります。なお、フェデレーションユーザーにはIdP側のMFAが掛かり、Cognito MFAの設定は効きません。既存IdPとの統合方式やテナント設計から検討したい場合は、認証基盤・ID管理システム開発でご相談いただけます。

よくある質問

CognitoのSAML連携とSSOの設計で、実装前によく確認される点をまとめました。

CognitoをSAMLのIdPにして他のサービスへSSOできますか？

できません。ユーザープールはSAMLではSPとしてだけ動き、外部IdPからアサーションを受け取る側です。Cognitoのユーザーで別のSaaSへSAMLサインインさせたい場合は、SAMLを発行できる別のIdPを用意する構成になります。一方で、ユーザープールはOIDC（OAuth 2.0）のトークンを発行できるため、OIDCに対応したアプリであればCognitoをそのままIdPとして使えます。

IdP起点（IdP-initiated）のSSOにも対応していますか？

対応しています。ProviderDetailsでIDPInitをtrueにすると、Entra IDのマイアプリなどから起動したSSOを受け付けます。ただし、IdP起点を有効にしたIdPを割り当てたアプリクライアントには他のSAML IdPしか追加できず、ローカルユーザーやOIDC、ソーシャルIdPとは併用できません。併用が必要なら、IdP起点用のアプリクライアントを別に作ってください。

SAMLでサインインしたユーザーのログアウトはどう扱われますか？

IDPSignoutをtrueにすると、Cognitoのログアウトエンドポイントを呼んだときにIdPへ署名付きのログアウトリクエストを送り、IdPのセッションも終えるシングルログアウトになります。IdPからの応答はHTTP POSTでsaml2/logoutへ返す必要があり、GETのバインディングは受け付けません。無効のままだとCognitoのセッションだけが消え、IdPのセッションは残ります。

Entra IDのグループをCognito側の権限判定に使えますか？

Entra IDでグループのクレームを追加し、Cognitoの変更可能なカスタム属性にマッピングすれば値は取り込めます。複数のグループは角括弧で囲んだカンマ区切りの1つの文字列になり、URLエンコードされる文字もあるため、アプリ側で分解が必要です。値は2,048文字が上限で、所属の多い社員では足りなくなります。ユーザープールのグループには自動で入らないので、トークン生成前のLambdaトリガーで組み替えるか、アプリ側で属性を見て判定します。

Google WorkspaceのアカウントはSAMLとGoogle連携のどちらで登録しますか？

Cognitoには個人のGoogleアカウント向けのソーシャルIdP（プロバイダー種別Google）があり、Workspaceのアカウントもこれでサインインできます。ただし、特定の組織のアカウントだけに絞る制御については、自前で実装する必要がある点に注意してください。組織単位でアクセスを管理したいなら、Workspace側でカスタムSAMLアプリを作り、本稿と同じ手順でSAML IdPとして登録する方が管理者の運用に沿います。