コグニトユーザープールとフェデレーションIDのAWSサービスの違い
AWSは cognito を提供します。これにより、開発者に、サインアップおよびサインイン機能が提供されます。これには、facebook、googleなどのOpenId互換IDプロバイダーとの連携が含まれます。
コグニト開発者コンソールには、2種類のカテゴリがあります。これらは、ユーザープールの管理とフェデレーションIDの管理です。
Facebookアカウントでログインするクライアントを提供したいのですが、どちらも非常に似ているため、少し混乱しています。コグニトユーザープール自体がフェデレーションを提供し、フェデレーションIDプールも認証プロバイダーによって提供されます。
問題は、クライアントがサインインに自分のFacebookアカウントを使用できるようにしたい場合、どのカテゴリを使用すればよいですか？ユーザープールまたはフェデレーションID？
さらに、APIゲートウェイでオーソライザーを構成する場合は、コグニトユーザープールを作成する必要がありますが、フェデレーションIDプールを作成します。これがコグニトカテゴリを選択する主な理由ですか。
ユーザープールは、名前、電子メール、電話番号などのユーザー属性を含むディレクトリの一種と考えることができます。これにより、サインアップ、サインイン機能も提供されます。ユーザーをユーザープールに統合できます。現在、ユーザープールのIDプロバイダーとしてFacebook、Google、SAMLを使用できます。
CognitoフェデレーテッドIDを使用すると、ユーザーをAWSに統合し、ポリシーで許可したリソースへのアクセスに使用できるAWS認証情報を提供できます。 CognitoフェデレーションIDの場合、Facebook、Googleなどの構成可能なさまざまなIDプロバイダーもあり、CognitoユーザープールをIDプロバイダーにすることもできます。
何を使用するかは、ユースケースによって異なります。アプリにAWSリソースが必要ない場合は、おそらくユーザープールで十分です。
Cognitoユーザープール：
Amazon Cognitoユーザープールを使用すると、開発者はサインアップおよびサインイン機能をウェブおよびモバイルアプリケーションに簡単に追加できます。これは、ユーザーディレクトリを維持するための独自のIDプロバイダーとして機能します。ユーザー登録とサインイン、およびサインインしたユーザーのIDトークンのプロビジョニングをサポートしています。
CognitoフェデレーションIDまたはIDプール：
一方、Cognito IDプール（またはCognitoフェデレーテッドID）は、ユーザーにさまざまなAWSサービスの使用を許可する方法です。ユーザーがS3バケットにアクセスできるようにして、ユーザーがファイルをアップロードできるようにしたいとします。 IDプールの作成時にそれを指定できます。これらのアクセスレベルを作成するために、IDプールにはID（またはユーザー）の独自の概念があります。これらのID（またはユーザー）のソースは、Cognitoユーザープール、あるいはFacebookやGoogleである可能性があります。
ユーザープールとIDプールの関係：
Cognito IDプールは、単純にすべてのIDプロバイダーを取得して、それらをまとめます（それらを統合します）。これらすべてにより、ユーザーがどこから来たかに関係なく、AWSサービスへの安全なアクセスをユーザーに提供できるようになりました。
つまり、要約すると、Cognitoユーザープールはすべてのユーザーを格納し、ユーザーはAWSサービスへのアクセス権をユーザーに付与できるCognito IDプールにプラグインします。
AWSはユーザープールをIDプールから分離する必要があると思います。両方を「AWS Cognito」の下に置き、それらを混同すると混乱が大きくなると思います。
IDプールに焦点を合わせる。ユーザープールは、Google、Facebook、Auth0などのIDプロバイダーサービスの1つにすぎないため、そのIDプールを利用できます。
準備
アイデンティティプールの機能にジャンプする前に、いくつかのことを理解することをお勧めします。
AWS STSトークン
単純に言うと、 AWS STS Token を使用すると、プログラムでAWSリソースを作成、使用、更新、削除できます。
- AWS_ACCESS_KEY_ID
- AWS_SECRET_ACCESS_KEY
- AWS_SESSION_TOKEN
AWSアカウントユーザーがいる場合は、そのユーザーのAWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEYを取得し、次にSTSトークンを取得できます。 MFA。
IAMの役割
実際には、IAMロールは、STSトークンのどのAWSリソースで許可されるアクションを定義します。 deleteは許可されない場合がありますが、createは許可されます。したがって、STSトークンで何ができるかはIAMロールに依存します。
ただし、注意すべき点はIAMロールとSTSトークンの関連付けがあり、誰かが関連付けを定義する必要があることです。
IDプールが提供するもの
STS Tokenが提供され、これを使用してAWSアカウントのAWSリソースを操作できます。
IDプールが役立つ状況
私にとってのAWSのもう1つの問題は、ドキュメントでIDプールが必要な場合と宣言されておらず、代わりに単語Federationを繰り返し続けることです。 、STSトークンを使用してAWSリソースを操作できるようにする。
次のような状況にある場合：
- AWSアカウントでAWSリソースを操作したい
- AWS IAMユーザーがいない（または使用したくない）が、
- 企業AD、Google、Facebook、Auth0、...、またはCognitoユーザープールにアカウントを持っています。
次に、IDプールを使用して、ログインしたGoogleなどのアカウントのSTSトークンを取得し、AWSリソースを操作できます。
たとえば、企業ADに1000人以上のユーザーがいて、何らかの方法でAWSリソースを使用できるようにする場合などです。 1000以上のAWS IAMユーザーを作成しますか？または、それらを「管理者」、「経理」、「金融」、「IT」などのいくつかのIAMロールにマップする方法を見つけますか？
IDプールの機能
IDプールはIDプロバイダートークン（Googleトークンなど）をAWSアカウントのIAMロールにマップし、STSトークンを提供します。
AWSは、この "マッピング"をFederationと呼んでいます。私の理解では。
IDプールについて話し合うときは、ユーザープールを完全に忘れることをお勧めします。ユーザープールは、まったく必要ない可能性があるもう1つのアイデンティティプロバイダーです。
同様に、ユーザープールについて説明するときは、IDプールを完全に忘れることをお勧めします。
AWSが混乱を引き起こさないように、IDプロバイダーサービス（ユーザープール）をトークンマッピングサービス（IDプール）から分離してくれることを願っています。
