Contents
OIDCとSAMLの選定基準
プロトコル選定時の主な判断軸を以下に比較します。
| 項目 | OIDC | SAML |
|---|---|---|
| 認証形式 | トークンベース（JSON） | XMLアサーションベース |
| 使用シーン | モバイル・Webアプリ向け | エンタープライズ・クラウド連携向け |
| 設定手順の複雑さ | 簡単で設定項目が少ない | 詳細なメタデータ処理が必要 |
OIDCは開発者にとって導入が簡単ですが、SAMLは既存の企業システムとの互換性に優れています。特に、フェデレーションロールの構成やリダイレクトURLの管理など、プロトコルごとに異なる仕様があるため注意が必要です。
Cognito連携の目的とユースケース
Cognitoは、外部IdPを介したAWSリソースへのアクセス制御が主な目的です。例えば、Azure AD経由でEC2に接続する際や、Google Workspaceユーザーをアプリケーションに認証させるケースがあります。
具体的なユースケースとして挙げられるのは以下の3つです：
- ユーザー管理の外部委譲（企業内のActive DirectoryをCognitoと連携）
- セキュアなSaaSアプリ開発（OAuth2.0経由で認証フローを実装）
- コスト削減（既存のIdPインフラを活用し、Cognito独自のユーザー管理を不要に）
いずれの場合も、loginsプロパティの正確な設定やフェデレーションロールの権限設計が成功の鍵となります。
Identity PoolとUser Poolでの連携差異
Identity PoolとUser Poolはどちらも外部IdPと連携可能です。しかし、認証フローの目的や役割管理の仕組みに大きな違いがあります。特に、フェデレーションロールの構成方法が異なるため、誤って設定するとアクセス権が付与されないケースが発生します。
Identity Poolのフェデレーションロール構成
Identity Poolは、外部IdP経由でユーザーを認証した後、AWSリソースへのアクセス権を付与するためのロールを設定します。この際、以下のように2つのロールが必要です：
- フェデレーションロール（IdPからの認証に基づく）
- 外部IdP（OIDC/SAML）を介してユーザーが認証された際に適用されるロール
-
IAMポリシーでAWSリソースへのアクセス権限を定義
-
デフォルトロール（未認証時やロールが見つからない場合の備え）
- ユーザーが外部IdP経由で認証されなかった時に適用されるロール
具体的な設定手順については後述します。
User Poolのプロバイダーコンフィグ設定
User Poolは、ユーザー登録・パスワードリセットなどの機能を備えたCognitoサービスです。外部IdPとの連携では、認証フローに追加の認証手段（フェデレーション）を提供することが目的です。
例えば、企業内ユーザーがGoogleアカウントでもログインできるように設定する場合、User Pool内にプロバイダーコンフィグとしてIdP情報を登録します。この際、OIDCまたはSAMLのメタデータファイルが必要となります。
loginsプロパティの正しい設定方法
外部IdPと連携させる際には、必ずloginsプロパティを正しく定義しなければなりません。このプロパティは、ユーザーがどのIdPから認証されたかを識別するためのキーであり、OIDC・SAMLそれぞれに応じた形式で指定します。
OIDCプロバイダーのProviderName指定
OIDCプロバイダーを使用する場合、loginsプロパティには以下のような構造になります：
|
1 2 3 4 |
"logins": { "oidc.<プロバイダーアカウントID>": "<ユーザーのIDトークン>" } |
- oidc.の直後にIdPの識別子（例：
oidc.google.com）を指定 - ユーザーのIDトークンは、認証フローで発行されるJSON形式の値
例として、Googleアカウントを使用した場合のloginsプロパティは以下のようになります：
|
1 2 3 4 |
"logins": { "oidc.google.com": "eyJsYXN0X2lkIjoic3ViamVjdCJ9" } |
SAMLプロバイダーのAssertionConsumerServiceURL入力
SAMLの場合、loginsプロパティには以下のような形式で設定します：
|
1 2 3 4 |
"logins": { "saml.<メタデータID>": "<SAMLアサーション>" } |
- saml.の後にIdPから取得したメタデータファイルに記載された識別子を指定
<SAMLアサーション>は、IdPが発行するXML形式の認証情報
注意点として、AssertionConsumerServiceURL（ACS URL）をCognito側とIdP側で一致させる必要があります。これは、後述の「リダイレクトURLのドメイン登録手順」で確認します。
リダイレクトURLのドメイン登録手順
認証フロー中に発生するリダイレクトURLは、CognitoとIdP双方で正しく設定されている必要があります。誤って指定すると、ユーザーがログイン画面に遷移できず、403エラーなどの不具合が発生します。
AWS Cognito設定画面でのURL追加
Cognitoの管理コンソールからリダイレクトURLを登録するには、以下の手順を行います：
- Identity PoolまたはUser Poolを開き、「プロバイダー」タブへ移動
- 新規IdPを追加し、リダイレクトURLのフィールドに以下を入力します：
https://<cognito-domain>.auth.<region>.amazoncognito.com/- 例：
https://myapp.auth.ap-northeast-1.amazoncognito.com/
このURLは、CognitoがIdPからの認証応答を受けるためのエンドポイントです。
IdP側で許可されたリダイレクト先確認
IdP側（例：Azure ADやGoogle Workspace）では、Cognitoが発行するURLをリダイレクト先として許可しているかを必ず確認してください。
- Azure ADの場合、アプリケーション設定の「ログインURL」に登録が必要です
- Google Workspaceでは、「OAuthクライアントID」にリダイレクトURLを追加します
メタデータファイルの作成・アップロード
SAMLプロバイダーと連携する際には、メタデータファイル（XML形式）の取得とCognitoへの登録が必要です。OIDCではこの手順は不要ですが、SAML導入時は必須となります。
SAMLプロバイダー向けXMLファイル生成
IdP側でメタデータファイルを取得するには、以下を行います：
- IdP管理画面にアクセスし、「メタデータ」または「フェデレーション設定」セクションを開く
- XML形式のメタデータをダウンロードします（例：Azure ADでは
https://login.microsoftonline.com/common/federationmetadata/2007-06/federationmetadata.xml）
このファイルには、ACS URLやIdPの識別子など、Cognito連携に必要な情報が含まれています。
OIDCプロバイダーのWell-Known Endpoint確認
OIDCではメタデータファイルではなく、.well-known/openid-configurationというエンドポイントから情報を取得します。
-
ブラウザで以下をアクセス：
https://<oidc-provider-domain>/.well-known/openid-configuration -
例：
https://accounts.google.com/.well-known/openid-configuration -
JSON形式のレスポンスから、issuerやauthorization_endpointなどの情報を確認し、Cognitoに設定します。
フェデレーションロールの設定ポイント
外部IdPを通じてAWSリソースへのアクセスを許可するには、フェデレーションロールを正しく構成することが不可欠です。特に、IAMポリシーの設計ミスがセキュリティリスクにつながるため、慎重に設定してください。
IAMロールの信頼ポリシーテンプレート
フェデレーションロールを作成する際は、信頼ポリシー（Trust Policy）を以下のように定義します：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::<AWSアカウントID>:oidc-provider/<oidcプロバイダードメイン>" }, "Action": "sts:AssumeRoleWithWebIdentity" } ] } |
- arn:aws:iam::に自身のAWSアカウントIDを入力
- Federatedフィールドは、IdPのプロバイダードメイン（例：
oidc.google.com）
SAMLの場合には、以下のように設定します：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::<AWSアカウントID>:saml-provider/<samlプロバイダードメイン>" }, "Action": "sts:AssumeRoleWithSAML" } ] } |
連携後のアクセス権付与ベストプラクティス
フェデレーションロールにAWSリソースへのアクセス権を付与する際は、以下のようなベストプラクティスに従ってください：
- 最小限の権限付与（Least Privilege）
-
ユーザーが必要とするリソースに限定してIAMポリシーを定義
-
ロールアサーションの検証
-
SAMLアサーションでは、
NameIDやAttributeStatementでユーザー情報を確認し、アクセス制限をかける -
定期的な権限見直し
- ユーザーが所属するグループやロールが変化した場合、ポリシーを見直す
まとめ
本記事では、Amazon Cognitoと外部IdPを連携させる際の設定手順・ポイントについて解説しました。主な要点は以下の通りです：
- OIDC/SAMLの選定基準に応じて、認証フローを設計する
- Identity Pool vs User Poolで役割管理の違いを理解し、適切な設定を行う
- loginsプロパティを正しく指定し、リダイレクトURLとメタデータファイルを登録
- フェデレーションロールを信頼ポリシーとともに慎重に構成する
外部IdP連携はAWS環境におけるセキュリティ設計の重要な一環です。設定ミスが発生しないよう、各手順を丁寧に実施してください。
おわりに
本記事で解説した手順により、Cognitoと外部IdPの連携を正確かつ効率的に実装できます。特に OIDC と SAML の技術的違いや、Identity Pool と User Pool の用途の違いを理解しておくことで、開発プロセスでのトラブルを大幅に減らすことが可能です。
AWSコンソールでの設定画面を参照しながら、実際に導入を進めることで、実務的な知識を確かなものにしてください。
