--- title: "Cognito SAML連携の手順：Entra IDでSSOを組む設定と属性マッピング" url: "https://www.issoh.co.jp/tech/details/18512/" published: 2026-10-18 updated: 2026-10-18 categories: ["AWS"] publisher: "株式会社一創" --- # Cognito SAML連携の手順：Entra IDでSSOを組む設定と属性マッピング 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検証まで](https://www.issoh.co.jp/tech/details/17445/)で土台を作ってから進めてください。IdPとSPの関係やアサーションの仕組みは[SAMLとは？認証フロー・IdP／SPの仕組みとOAuth・OIDCとの使い分け](https://www.issoh.co.jp/tech/details/13299/)で解説しています。 ### IdPへ登録するSPエンティティIDとACS URLとアサーションの必須要素 IdP側に登録する値は、[CognitoのSAML IdPに関する公式の注意事項](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-saml-idp-things-to-know.html)で決まっています。プール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の公式ガイド](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-oidc-idp.html)と並べると明確です。 | 観点 | 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の料金ページ](https://aws.amazon.com/cognito/pricing/)では、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を登録する手順 1. Entra管理センターのエンタープライズアプリケーションで、ギャラリー外の独自アプリを新規作成する 2. シングルサインオンの方式でSAMLを選び、基本的なSAML構成の識別子に`urn:amazon:cognito:sp:ap-northeast-1_EXAMPLE`を入れる 3. 応答URLに`https://auth.example.co.jp/saml2/idpresponse`のようにプールのドメインのACS URLを入れる 4. SAML証明書の欄にある「アプリのフェデレーションメタデータURL」を控える 5. ユーザーとグループで、サインインを許可するユーザーまたはグループを割り当てる カスタムドメインを使うなら、応答URLもそのドメインで登録します。後からドメインを変えるとIdP側の登録もやり直しになるため、本番ドメインで最初から作る方が手戻りの少ない方法です。メタデータはファイルのアップロードより、URLで渡す方が証明書の更新に自動で追随できます。 ### NameIDの既定値UPNをオブジェクトIDに変えてユーザーの重複を防ぐ [Microsoft LearnのSAMLクレームの説明](https://learn.microsoft.com/en-us/entra/identity-platform/saml-claims-customization)のとおり、Entra IDは既定でユーザーのUPNをNameIDとして送ります。一方Cognitoは、NameIDが変わると新しいユーザーとみなす仕様です。改姓、部署統合によるドメイン変更、UPNの命名規則の見直しのどれかが起きると、同じ社員に2つ目のプロファイルができ、アプリ側のデータとの紐づけが切れます。 対策は、属性とクレームの画面で名前識別子の値を`user.objectid`に変え、形式をPersistentにすることです。Cognitoのユーザー名は「プロバイダー名\_NameID」となり、大文字小文字を区別しないプールでは全体が小文字になります。メールアドレスは別のクレームで送り、属性マッピングで`email`に入れれば表示や通知に利用可能です。NameIDの形式が噛み合わずに失敗するときは[SAML NameIDFormatとメタデータの不一致でSSOが失敗する原因の切り分け](https://www.issoh.co.jp/tech/details/17589/)が参考になります。 ## AWS CLIでSAML IdPを登録し属性マッピングとアプリクライアントを設定する Cognito側はコンソールの「ソーシャルプロバイダーと外部プロバイダー」からも追加できますが、ここでは再現しやすいAWS CLIの例を示します。 ### create-identity-providerでメタデータURLとクレームURIを渡す [CreateIdentityProviderのAPIリファレンス](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API%5FCreateIdentityProvider.html)によると、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](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API%5FUpdateUserPoolClient.html)は指定しなかった項目を既定値に戻すため、先に現在の設定を控え、既存の値もすべて渡してください。 ``` # 現在の設定を控える（未指定の項目は既定値に戻るため） 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（マネージドログイン）のカスタマイズ・日本語化と実装手順](https://www.issoh.co.jp/tech/details/3441/)で扱っています。 ### 属性マッピングで詰まる必須属性・変更可能属性・書き込み権限の3条件 [属性マッピングの公式ガイド](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-specifying-attribute-mapping.html)が挙げる条件のうち、サインインの失敗に直結するのは次の3つです。 - プールで必須にした属性（多くは`email`）すべてに、IdPのクレームを割り当てている - マッピング先のカスタム属性を先にスキーマへ追加し、変更可能（Mutable）にしている - アプリクライアントの書き込み権限に、マッピングした属性がすべて含まれている 変更不可の属性にIdPから値が届くと、サインインは失敗します。書き込み権限が無い場合の挙動は、値を更新せず認証を続けると書く資料と、エラーになると書く資料があり、公式の記述が揃っていません。どちらでも不具合になるため、権限は必ず付けます。マッピングしたメールアドレスは未検証の扱いで、ワンタイムコードでの検証もできません。値の長さは2,048文字までです。 ## 取引先ごとのIdP振り分けと既存のローカルユーザーとの紐づけを実装する IdPが1つなら前章までで動きます。複数の会社の社員を受ける場合と、パスワード認証からSSOへ移行する場合は、もう一段の実装が必要です。 ### IdP識別子にメールドメインを登録して取引先ごとのIdPへ振り分ける BtoB SaaSのように1つのアプリで複数の会社を受けるなら、会社ごとにSAML IdPを登録し、[IdP識別子](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-managing-saml-idp-naming.html)にその会社のメールドメインを入れます。識別子はプール全体で最大50個で、1つのIdPに複数のドメインを持たせる設定も可能です。マネージドログインはメールアドレスの入力を求め、ドメインが一致したIdPへ転送します。 注意点は2つあります。マネージドログインでこの入力欄を出すには、ブランディングエディタで「Domain search input」を有効にする設定が必要です。また、アプリクライアントに割り当てたSAML IdPのすべてに識別子を付けると、IdPを選ぶボタンは表示されなくなります。自前のログイン画面で振り分けるなら、認可リクエストに`idp_identifier=example.co.jp`を付ければ同じ転送ができます。 ### 既存ユーザーをAdminLinkProviderForUserでSAMLと紐づける パスワードでサインインしていた既存ユーザーをSSOへ移す場合、何もしないと初回のSAMLサインインで別のユーザーが作られ、権限やデータが引き継がれません。[AdminLinkProviderForUser](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API%5FAdminLinkProviderForUser.html)で、まだサインインしていない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で認証を後付けする手順](https://www.issoh.co.jp/tech/details/18501/)で扱うリスナールールの認証アクションで後付けする方法もあります。 採用の条件は、IdPが複数ある、将来増える見込みがある、ローカルユーザーと混在する、のどれかに当てはまることです。どれにも当てはまらなければ見送ります。なお、フェデレーションユーザーにはIdP側のMFAが掛かり、[Cognito MFAの設定](https://www.issoh.co.jp/tech/details/18510/)は効きません。既存IdPとの統合方式やテナント設計から検討したい場合は、[認証基盤・ID管理システム開発](https://www.issoh.co.jp/service/system/identity/)でご相談いただけます。 ## よくある質問 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として登録する方が管理者の運用に沿います。 ## 関連記事 - [Amazon Cognito（コグニート）とは？料金・できること・使い方をCLIとコード例で解説](https://www.issoh.co.jp/tech/details/3108/)：機能プランごとの料金とCognitoの基本。 - [フェデレーション認証とは？IdPとSPの信頼設計と属性連携を実装視点で解説](https://www.issoh.co.jp/tech/details/16413/)：製品に依存しないフェデレーションの信頼設計とJIT・SCIM。 - [IDaaSとは？SSO・IdPとの違いとSAML・OIDC・SCIM連携を実装視点で解説](https://www.issoh.co.jp/tech/details/16401/)：Entra IDやOktaなどIdP側の選び方。 - [認証・ID管理とは？MFA・SSO・OIDC・IDaaSの違いと選び方](https://www.issoh.co.jp/column/details/13631/)：SSOやMFAを含む認証基盤全体の整理。 - [Cognitoで認証基盤を実装する手順：ユーザープール構築からJWT検証まで](https://www.issoh.co.jp/tech/details/17445/)：SAMLで発行されたトークンの検証まで含む全体像。 --- 出典: [Cognito SAML連携の手順：Entra IDでSSOを組む設定と属性マッピング]()（株式会社一創）