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 ロール」を参照してください。

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

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

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

拡張認証フローを使用する場合、アプリケーションは最初に、GetId リクエストで、認可された Amazon Cognito ユーザープールまたはサードパーティー ID プロバイダーからの認証の証拠を示します。

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

  2. アイデンティティプールはアイデンティティ ID を返します。

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

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

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

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

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

  1. GetId

  2. GetCredentialsForIdentity

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

基本 (Classic) 認証フロー

基本認証フローを使用する場合、

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

  2. アイデンティティプールはアイデンティティ ID を返します。

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

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

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

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

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

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

ロールマッピングがないユーザープールの基本認証フローを使用してサインインできます。このタイプのアイデンティティプールには、デフォルトの認証されているロールまたは認証されていないロールはなく、ロールベースのアクセス制御または属性ベースのアクセス制御も設定されていません。ロールマッピングを使用してアイデンティティプールで GetOpenIdToken を試行すると、次のエラーが表示されます。

Basic (classic) flow is not supported with RoleMappings, please use enhanced flow.
基本認証でのオペレーションの順序

  1. GetId

  2. GetOpenIdToken

  3. AssumeRoleWithWebIdentity

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

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

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

拡張認証フロー

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

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

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

  3. GetOpenIdTokenForDeveloperIdentity

  4. GetCredentialsForIdentity

デベロッパー認証の拡張認証のフローを示す図
デベロッパープロバイダーによる基本認証でのオペレーションの順序

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

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

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

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

デベロッパー認証の基本認証のフローを示す図

使用するべき認証フロー

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

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

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

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

重要

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

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

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

API の要約

GetId

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

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

Amazon Cognito には、アプリケーションで認証されていないゲストアクセスを許可できます。この機能が ID プールで有効になっている場合、ユーザーはいつでも GetId API 経由で新しいアイデンティティ ID をリクエストできます。Amazon Cognito に後続のコールを実行するため、アプリケーションにはこのアイデンティティ ID をキャッシュすることが期待されます。ブラウザの AWS AWS Mobile SDKs と 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 オペレーションは、デベロッパーが認証した ID を使用するときに、デバイスから GetId と GetOpenIdToken の使用を置き換えます。アプリケーションは 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 の結合

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

AssumeRoleWithWebIdentity

OpenID Connect トークンを取得したら、 AWS Security Token Service () への AssumeRoleWithWebIdentity 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 (US-West) https://cognito-identity.us-gov-west-1.amazonaws.com/.well-known/jwks_uri
China (Beijing) https://cognito-identity.cn-north-1.amazonaws.com.cn/.well-known/jwks_uri
Opt-in Regions like Europe (Milan) and Africa (Cape Town) https://cognito-identity.Region.amazonaws.com/.well-known/jwks_uri

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