ID プール (フェデレーティッドアイデンティティ) の認証フロー - Amazon Cognito

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ID プール (フェデレーティッドアイデンティティ) の認証フロー

Amazon Cognito は、エンドユーザーのために、デバイスおよびプラットフォーム全体で整合性が維持される一意の識別子を作成するために役立ちます。また、Amazon Cognito は、 AWS リソースにアクセスするために、権限が制限された一時的な認証情報をアプリケーションに配信します。このページでは、Amazon Cognito での認証の基礎と、ID プール内のアイデンティティのライフサイクルについて説明します。

外部プロバイダーの認証フロー

Amazon Cognito で認証されるユーザーは、その認証情報をブートストラップするために複数ステップのプロセスを経由します。Amazon Cognito には、パブリックプロバイダーでの認証に、拡張認証と基本認証の 2 つの異なるフローがあります。

これらのフローのいずれかを完了すると、ロールのアクセスポリシーで定義されている AWS のサービス 他の にアクセスできます。デフォルトでは、Amazon Cognito コンソールは、Amazon Cognito Sync ストアと Amazon Mobile Analytics へのアクセス権を持つロールを作成します。その他のアクセス権を付与する方法の詳細については、「IAM ロール」を参照してください。

ID プールは、プロバイダーからの次のアーティファクトを受け入れます。

プロバイダー 認証アーティファクト
Amazon Cognito ユーザープール ID トークン
OpenID Connect (OIDC) ID トークン
SAML 2.0 SAML アサーション
ソーシャルプロバイダー アクセストークン

拡張 (簡略化) 認証フロー

拡張認証フローを使用する場合、アプリはまず、承認された Amazon Cognito ユーザープールまたはサードパーティー ID プロバイダーからの認証の証明をGetIdリクエストで提示します。

  1. アプリケーションは、GetID リクエストで、認可された Amazon Cognito ユーザープールまたはサードパーティー ID プロバイダーからの JSON ウェブトークンまたは SAML アサーションなどの認証の証明を提示します。 GetID

  2. ID プールは ID を返します。

  3. アプリケーションは、ID をGetCredentialsForIdentityリクエスト内の同じ認証証明と組み合わせます。

  4. ID プールは AWS 認証情報を返します。

  5. アプリケーションは、一時的な認証情報を使用して AWS API リクエストに署名します。

拡張認証は、アイデンティティプール設定での IAM ロールの選択と認証情報の取得のロジックを管理します。デフォルトのロールを選択するように ID プールを設定して、属性ベースのアクセスコントロール (ABAC) またはロールベースのアクセスコントロール (RBAC) の原則をロール選択に適用できます。拡張認証の AWS 認証情報は 1 時間有効です。

拡張認証でのオペレーションの順序

  1. GetId

  2. GetCredentialsForIdentity

拡張認証のフローを示す図

基本 (Classic) 認証フロー

基本的な認証フローを使用すると、

  1. アプリケーションは、GetID リクエストで、認可された Amazon Cognito ユーザープールまたはサードパーティー ID プロバイダーからの JSON ウェブトークンまたは SAML アサーションなどの認証の証明を提示します。 GetID

  2. ID プールは ID を返します。

  3. アプリケーションは、ID をGetOpenIdTokenリクエスト内の同じ認証証明と組み合わせます。

  4. GetOpenIdToken は、ID プールによって発行された新しい OAuth 2.0 トークンを返します。

  5. アプリケーションは新しいトークンを AssumeRoleWithWebIdentityリクエストに提示します。

  6. AWS Security Token Service AWS STS) は AWS 認証情報を返します。

  7. アプリケーションは、一時的な認証情報を使用して AWS API リクエストに署名します。

基本ワークフローでは、ユーザーに配布する認証情報をより細かく制御できます。拡張認証フローの GetCredentialsForIdentity リクエストは、アクセストークンの内容に基づいてロールをリクエストします。クラシックワークフローのAssumeRoleWithWebIdentityリクエストにより、十分な信頼ポリシーで設定した AWS Identity and Access Management ロールの認証情報をリクエストする機能がアプリに付与されます。カスタムロールセッション期間をリクエストすることもできます。

基本認証でのオペレーションの順序

  1. GetId

  2. GetOpenIdToken

  3. AssumeRoleWithWebIdentity

基本認証のフローを示す図

デベロッパーが認証した ID の認証フロー

デベロッパーが認証したアイデンティティ (アイデンティティプール) を使用する場合、クライアントは独自の認証システムでユーザーを検証するために、Amazon Cognito 外部のコードが含まれる異なる認証フローを使用します。Amazon Cognito 外部のコードは、外部のものであることが示されます。

拡張認証フロー

デベロッパープロバイダーによる拡張認証でのオペレーションの順序

  1. デベロッパープロバイダー経由でのログイン (Amazon Cognito 外部のコード)

  2. ユーザーログインの検証 (Amazon Cognito 外部のコード)

  3. GetOpenIdTokenForDeveloperIdentity

  4. GetCredentialsForIdentity

開発者が認証した拡張認証の流れを示す図
デベロッパープロバイダーによる基本認証でのオペレーションの順序

  1. ID プールの外部にロジックを実装してサインインし、デベロッパーとプロバイダーの識別子を生成します。

  2. 保存されたサーバー側の AWS 認証情報を取得します。

  3. 承認された AWS 認証情報で署名された GetOpenIdTokenForDeveloperIdentity API リクエストでデベロッパープロバイダー識別子を送信します。

  4. でアプリケーション認証情報をリクエストしますAssumeRoleWithWebIdentity。

デベロッパーが認証した基本認証の流れを示す図

使用するべき認証フロー

拡張フローは、デベロッパーの労力が最も低い、最も安全な選択肢です。

  • 拡張フローにより、API リクエストの複雑さ、サイズ、レートが軽減されます。

  • アプリケーションは、 に追加の API リクエストを行う必要はありません AWS STS。

  • ID プールは、ユーザーに対して、受信する必要がある IAM ロール認証情報を評価します。クライアントでロールを選択するためにロジックを埋め込む必要はありません。

重要

新しい ID プールを作成するときは、ベストプラクティスとして、基本 (クラシック) 認証をデフォルトでアクティブ化しないでください。基本認証を実装するには、まず IAM ロールのウェブ ID の信頼関係を評価します。次に、クライアントにロール選択のロジックを構築し、ユーザーによる変更からクライアントを保護します。

基本的な認証フローは、IAM ロール選択のロジックをアプリケーションに委任します。このフローでは、Amazon Cognito はユーザーの認証されたセッションまたは認証されていないセッションを検証し、 と認証情報と交換できるトークンを発行します AWS STS。ユーザーは、基本認証からトークンを、ID プールと を信頼する任意の IAM ロールamr、または認証済み/未認証の状態と交換できます。

同様に、デベロッパー認証は ID プロバイダー認証の検証に関するショートカットであることを理解してください。Amazon Cognito は、GetOpenIdTokenForDeveloperIdentityリクエストの内容をさらに検証することなく、リクエストを承認する AWS 認証情報を信頼します。ユーザーによるアクセスからデベロッパー認証を許可するシークレットを保護します。

API の要約

GetId

GetId API コールは、Amazon Cognito で新しい ID を確立するために必要な最初のコールです。

非認証アクセス

Amazon Cognito には、アプリケーションで認証されていないゲストアクセスを許可できます。この機能が ID プールで有効になっている場合、ユーザーはいつでも GetId API 経由で新しいアイデンティティ ID をリクエストできます。Amazon Cognito に後続のコールを実行するため、アプリケーションにはこのアイデンティティ ID をキャッシュすることが期待されます。ブラウザの Mobile SDKs AWS と AWS SDK for には JavaScript 、このキャッシュを処理する認証情報プロバイダーがあります。

認証されたアクセス

パブリックログインプロバイダー (Facebook、Google+、Login with Amazon、または「Apple でサインイン」など) のサポートでアプリケーションを設定すると、ユーザーは、これらのプロバイダーでユーザーを識別するトークン (OAuth または OpenID Connect) を提供できるようになります。GetId の呼び出しで使用されると、Amazon Cognito は新しい認証されたアイデンティティを作成するか、その特定のログインに既に関連付けられているアイデンティティを返します。Amazon Cognito は、プロバイダーでトークンを検証し、以下を確実にすることでこれを行います。

  • トークンは有効で、設定されたプロバイダーからのものである。

  • トークンの有効期限が切れていない。

  • トークンがそのプロバイダーで作成されたアプリケーション識別子 (例えば、Facebook アプリ ID) と一致する。

  • トークンがユーザー識別子と一致する。

GetCredentialsForIdentity

GetCredentialsForIdentity API は、ID を確立した後に呼び出すことができます。このオペレーションは、機能的には を呼び出しGetOpenIdToken、次に を呼び出すのと同等ですAssumeRoleWithWebIdentity。

代わりに Amazon Cognito で AssumeRoleWithWebIdentity を呼び出す場合は、Amazon Cognito に関連付けられた IAM ロールが ID プールにある必要があります。これは、Amazon Cognito コンソールまたは SetIdentityPoolRolesオペレーションを使用して手動で実行できます。

GetOpenIdToken

ID を確立した後に GetOpenIdToken API リクエストを行います。最初のリクエスト後にアイデンティティ ID をキャッシュし、GetOpenIdToken を使用してその ID 以降の基本 (クラシック) セッションを開始します。

GetOpenIdToken API リクエストに対するレスポンスは、Amazon Cognito が生成するトークンです。このトークンは、 AssumeRoleWithWebIdentityリクエストの WebIdentityTokenパラメータとして送信できます。

OpenID トークンを送信する前に、アプリで検証してください。SDK の OIDC ライブラリや aws-jwt-verify のようなライブラリを使用して、Amazon Cognito がトークンを発行したことを確認できます。OpenID トークンの署名キー ID または kid は、Amazon Cognito ID jwks_uriドキュメント† にリストされているもののいずれかです。これらのキーは変更される可能性があります。Amazon Cognito ID トークンを検証する関数は、jwks_uri ドキュメントからキーのリストを定期的に更新する必要があります。Amazon Cognito は、jwks_uri キャッシュコントロールレスポンスヘッダーで更新期間を設定しており、現在 max-age の 30 日間に設定されています。

認証されていないアクセス

認証されていない ID のトークンを取得するには、アイデンティティ ID そのもののみが必要です。認証された ID または無効にした ID の認証されていないトークンを取得することはできません。

認証されたアクセス

認証済みの ID がある場合、その ID に既に関連付けられたログイン用に、少なくとも 1 つのトークンを渡す必要があります。GetOpenIdToken の呼び出し中に渡されるすべてのトークンは、前に説明したのと同じ検証を渡す必要があります。いずれかのトークンが失敗すると、呼び出し全体が失敗します。GetOpenIdToken 呼び出しからの応答に、アイデンティティ ID が含まれることもあります。これは、渡すアイデンティティ ID が、返される ID とは限らないためです。

ログインのリンク

既に任意の ID と関連付けられていないログインのトークンを送信すると、そのログインは関連付けられた ID に「リンクしている」と見なされます。パブリックプロバイダーごとに、1 つのログインのみをリンクできます。複数のログインをパブリックプロバイダーにリンクしようとすると、応答として ResourceConflictException エラーが発生します。ログインが単純に既存の アイデンティティ にリンクされている場合、GetOpenIdToken から返されるアイデンティティ ID は、渡された ID と同じになります。

ID の結合

現在、特定の ID にリンクされていないが、別の ID にリンクされているログインに対してトークンを渡すと、2 つの ID が結合されます。いったん結合されると、1 つの ID は、すべての関連ログインの親/所有者になり、もう 1 つは無視されます。この場合、親/所有者のアイデンティティ ID が返されます。この値が異なる場合は、ローカルキャッシュを更新する必要があります。ブラウザの AWS Mobile SDKs または AWS SDK for JavaScript のプロバイダーが、このオペレーションを実行します。

GetOpenIdTokenForDeveloperIdentity

GetOpenIdTokenForDeveloperIdentity オペレーションは、デベロッパーGetOpenIdTokenが認証した ID を使用する場合の、デバイスから GetIdおよび の使用を置き換えます。アプリケーションは AWS 認証情報を使用してこの API オペレーションへのリクエストに署名するため、Amazon Cognito はリクエストで指定されたユーザー識別子が有効であると信頼します。デベロッパー認証は、Amazon Cognito が実行するトークン検証を外部プロバイダーに置き換えます。

この API のペイロードにはloginsマップが含まれています。このマップには、デベロッパープロバイダーのキーと、システム内のユーザーの識別子としての 値が含まれている必要があります。ユーザー識別子がまだ既存のアイデンティティに既にリンクされていない場合は、Amazon Cognito が新しいアイデンティティを作成して、新しいアイデンティティ ID と、そのアイデンティティの OpenID Connect を返します。ユーザー識別子が既にリンクされている場合は、Amazon Cognito が既存のアイデンティティ ID と OpenID Connect トークンを返します。最初のリクエスト後にデベロッパーアイデンティティ ID をキャッシュし、GetOpenIdTokenForDeveloperIdentity を使用してその ID 以降の基本 (クラシック) セッションを開始します。

GetOpenIdTokenForDeveloperIdentity API リクエストに対するレスポンスは、Amazon Cognito が生成するトークンです。このトークンは、AssumeRoleWithWebIdentity リクエストの WebIdentityToken パラメータとして送信できます。

OpenID Connect トークンを送信する前に、アプリで検証してください。SDK の OIDC ライブラリや aws-jwt-verify のようなライブラリを使用して、Amazon Cognito がトークンを発行したことを確認できます。OpenID Connect トークンの署名キー ID または kid は、Amazon Cognito ID jwks_uri ドキュメント† にリストされているもののいずれかです。これらのキーは変更される可能性があります。Amazon Cognito ID トークンを検証する関数は、jwks_uri ドキュメントからキーのリストを定期的に更新する必要があります。Amazon Cognito は、jwks_uri cache-control レスポンスヘッダーで更新期間を設定しており、現在 max-age の 30 日間に設定されています。

ログインのリンク

外部プロバイダーと同様に、既に ID に関連付けられていない追加のログインを指定すると、それらのログインがその ID に暗黙的にリンクされます。外部プロバイダーのログインを ID にリンクする場合、ユーザーはそのプロバイダーで外部プロバイダーの認証フローを使用できます。ただし、GetId または GetOpenIdToken を呼び出すときに、ログインマップで開発者プロバイダ名を使用することはできません。

ID の結合

デベロッパーが認証した ID では、Amazon Cognito は MergeDeveloperIdentities API を介した暗黙的なマージと明示的なマージの両方をサポートします。明示的なマージにより、システムでユーザー識別子を持つ 2 つのアイデンティティを、1 つのアイデンティティとしてマークできます。ソースと宛先のユーザー識別子を指定すると、Amazon Cognito がそれらをマージします。次回にいずれかのユーザー識別子に対して OpenID Connect トークンをリクエストすると、同じアイデンティティ ID が返されます。

AssumeRoleWithWebIdentity

OpenID Connect トークンを取得したら、これを () への AssumeRoleWithWebIdentity AWS Security Token Service API リクエストを通じて一時的な AWS 認証情報と交換できますAWS STS。

作成できる ID の数には制限がないため、ユーザーに付与するアクセス権限を理解することが重要です。アプリケーションに異なる IAM ロールを設定します。1 つは認証されていないユーザー用、もう 1 つは認証されたユーザー用です。Amazon Cognito コンソールでは、アイデンティティプールを初めてセットアップするときにデフォルトのロールを作成できます。これらのロールには、実質的にアクセス許可が付与されていません。ニーズに合わせて変更します。

ロールの信頼とアクセス権限 の詳細を確認してください。

† デフォルトの Amazon Cognito ID の jwks_uri ドキュメントには、ほとんどの AWS リージョンで ID プールのトークンに署名するキーに関する情報が含まれています。以下のリージョンには異なる jwks_uri ドキュメントがあります。

Amazon Cognito Identity JSON web key URIs in other AWS リージョン
AWS リージョン jwks_uri ドキュメントへのパス
AWS GovCloud （米国西部） https://cognito-identity.us-gov-west-1.amazonaws.com/.well-known/jwks_uri
中国 (北京) https://cognito-identity---cn-north-1.amazonaws.com.rproxy.goskope.com.cn/.well-known/jwks_uri
欧州 (ミラノ) やアフリカ (ケープタウン) などのオプトインリージョン https://cognito-identity.Region.amazonaws.com/.well-known/jwks_uri

また、発行者から jwks_uri を推定することも、Amazon Cognito から OpenID トークンで受け取った iss を推定することもできます。OIDC 標準の検出エンドポイント <issuer>/.well-known/openid-configuration には、トークンの jwks_uri へのパスがリストされます。