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 アサーション
ソーシャルプロバイダー アクセストークン

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

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

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

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

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

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

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

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

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

  1. GetId

  2. GetCredentialsForIdentity

拡張認証の流れを示す図

基本 (Classic) 認証フロー

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

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

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

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

  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 ロールの認証情報をリクエストする機能がアプリに付与されます。カスタムロールセッション期間をリクエストすることもできます。

ロールマッピングがないユーザープールの基本的な認証フローを使用してサインインできます。このタイプの ID プールには、デフォルトの認証ロールまたは未認証ロールがなく、ロールベースまたは属性ベースのアクセスコントロールが設定されていません。ロールマッピングを使用して ID プール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. ID プールの外部にロジックを実装してサインインし、デベロッパープロバイダー識別子を生成します。

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

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

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

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

使用するべき認証フロー

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

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

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

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

重要

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

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

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

API 概要

GetId

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

非認証アクセス

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

認証されたアクセス

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

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

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

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

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

GetCredentialsForIdentity

ID を確立した後、 を呼び出すGetCredentialsForIdentityAPIことができます。このオペレーションは、関数的に を呼び出してから GetOpenIdTokenを呼び出すのと同等ですAssumeRoleWithWebIdentity。

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

GetOpenIdToken

ID を確立した後にGetOpenIdTokenAPIリクエストを行います。最初のリクエストIDs後に ID をキャッシュし、その ID のその後の基本 (クラシック) セッションを で開始しますGetOpenIdToken。

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

OpenID トークンを送信する前に、アプリで検証してください。OIDC ライブラリは、 SDKまたは などのライブラリで使用できます。 aws-jwt-verify Amazon Cognito がトークンを発行したことを確認します。OpenID トークンの署名キー ID kidまたは は、Amazon Cognito Identity に記載されているもののいずれかです。 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 が が返されparent/owner of all associated logins and the other is disabled. In this case, the identity ID of the parent/ownerます。この値が異なる場合は、ローカルキャッシュを更新する必要があります。Mobile SDKsまたは AWS SDK Browser の AWS JavaScript のプロバイダーは、このオペレーションを実行します。

GetOpenIdTokenForDeveloperIdentity

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

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

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

OpenID Connect トークンを送信する前に、アプリで検証してください。OIDC ライブラリは、 SDKまたは などのライブラリで使用できます。 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 は を介した暗黙的なマージと明示的なマージの両方をサポートしますMergeDeveloperIdentitiesAPI。明示的なマージにより、システムでユーザー識別子を持つ 2 つのアイデンティティを、1 つのアイデンティティとしてマークできます。ソースと宛先のユーザー識別子を指定すると、Amazon Cognito がそれらをマージします。次回にいずれかのユーザー識別子に対して OpenID Connect トークンをリクエストすると、同じアイデンティティ ID が返されます。

AssumeRoleWithWebIdentity

OpenID Connect トークンを取得したら、これを AWS Security Token Service () へのAssumeRoleWithWebIdentityAPIリクエストを通じて一時的な 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.cn/.well-known/jwks_uri
欧州 (ミラノ) やアフリカ (ケープタウン) などのオプトインリージョン https://cognito-identity.Region.amazonaws.com/.well-known/jwks_uri

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