一般的なシナリオ

注記

人間のユーザーが AWS にアクセスする際は、一時的な認証情報の使用を必須とすることをお勧めします。AWS IAM Identity Center の使用を検討したことのある場合 IAM Identity Center を使用すると、複数の AWS アカウント へのアクセスを一元的に管理できます。ユーザーには、割り当てられたすべてのアカウントに対する MFA で保護された Single Sign-On によるアクセスを、1 つの場所から提供することができます。IAM Identity Center では、 その内部でユーザー ID の作成および管理を行います。あるいは、既存の SAML 2.0 互換 ID プロバイダーにも簡単に接続することができます。詳細については、「AWS IAM Identity Center ユーザーガイド」の「What is IAM Identity Center?」(IAM Identity Center とは?) を参照してください。

外部 ID プロバイダー (IdP) を使用して、AWS と外部 IdP 外のユーザー ID を管理できます。外部 IdP は、OpenID Connect (OIDC) または Security Assertion Markup Language (SAML) のいずれかを使用して ID 情報を AWS に提供できます。OIDC は、AWS 上で実行しないアプリケーションが AWS リソースにアクセスする必要がある場合に広く使用されます。

外部 IdP サービスとの連携を設定する場合、IAM の ID プロバイダーを作成し、外部 IdP とその設定について AWS に通知します。これにより、AWS アカウント と外部 IdP の間の信頼が確立されます。以下のトピックでは、IAM ID プロバイダーを使用する一般的なシナリオについて説明します。

モバイルアプリのための Amazon Cognito

OIDC フェデレーションの推奨される使い方は、Amazon Cognito を使用することです。たとえば、開発者の Adele は、モバイルデバイス用のゲームを開発しています。スコアやプロファイルのようなユーザーデータは Amazon S3 と Amazon DynamoDB に保存します。Adele はこのデータを 1 台のデバイスにローカルで保存して、Amazon Cognito を使って他のデバイス間で同期を取ることもできます。セキュリティおよびメンテナンス上の理由により、長期的な AWS セキュリティ認証情報をこのゲームで配布することはできません。また、このゲームが多数のユーザーを集めることもわかっています。以上のような理由から、IAM でプレーヤーごとに新しいユーザー ID を作成することはしません。代わりに、ユーザーがよく知られた外部 ID プロバイダー (IdP) (Login with Amazon、Facebook、Google など) や任意の OpenID Connect (OIDC) 互換の IdP ですでに確立した ID を使用してサインインできるようにゲームを開発します。ゲームでは、このようなプロバイダーの認証メカニズムを活用して、ユーザーの ID を検証できます。

モバイルアプリから自分の AWS リソースにアクセスできるようにするために、Adele はまず自分の選択した IdP に開発者 ID を登録します。また、これらのプロバイダーそれぞれについてアプリケーションを設定します。ゲーム用の Amazon S3 バケットおよび DynamoDB テーブルを含む AWS アカウント で、Amazon Cognito を使用して、ゲームに必要なアクセス許可を厳密に定義する IAM ロールを作成します。OIDC IdP を使用している場合は、IAM OIDC ID プロバイダーのエンティティも作成して、AWS アカウント 内の Amazon Cognito ID プールと IdP の間に信頼を確立します。

アプリのコードでは、前の手順で設定した IdP のサインインインターフェイスを呼び出します。IdP がユーザーのサインイン操作をすべて処理し、アプリは OAuth アクセストークンまたは OIDC ID トークンをプロバイダーから取得します。アプリは、この認証情報を、AWS アクセスキー ID、シークレットアクセスキー、およびセッショントークンで構成される一時的セキュリティ認証情報のセットと交換できます。その後、アプリはこれらの認証情報を使用して、AWS によって提供されるウェブサービスにアクセスできます。アプリは、引き受けるロールで定義されているアクセス権限に制限されます。

以下の図は、この処理の流れを単純化して示しており、IdP として Login with Amazon を使用しています。ステップ 2 については、アプリで、Facebook、Google、その他の OIDC 互換 IdP を利用することもできますが、この図には示していません。

1. 顧客はモバイルデバイスでアプリを起動します。アプリはユーザーにサインインするように求めます。

2. アプリは Login with Amazon を使用して、ユーザーの認証情報を承認します。

3. このアプリは Amazon Cognito API オペレーションの GetId と GetCredentialsForIdentity を使用して、Login with Amazon ID トークンを Amazon Cognito トークンに置き換えます。Login with Amazon プロジェクトを信頼するように設定されている Amazon Cognito は、一時的なセッション認証情報として AWS STS と交換するトークンを生成します。

4. このアプリで Amazon Cognito から一時的なセキュリティ認証情報を受信します。また、アプリは Amazon Cognito のベーシック (クラシック) ワークフローを使用して、AssumeRoleWithWebIdentity を使用する AWS STS からトークンを取得します。詳細については、「Amazon Cognito 開発者ガイド」の「ID プール (フェデレーション ID) 認証フロー」を参照してください。

5. アプリは一時的なセキュリティ証明書を使用して、アプリの動作に必要ないずれの AWS リソースにもアクセスできます。一時的なセキュリティ証明書に関連付けられたロールとその割り当てられたポリシーによって、アクセス可能なリソースが決まります。

以下のプロセスに従って、Amazon Cognito を使用してユーザーを認証してアプリに AWS リソースに対するアクセス許可を付与するように、アプリを設定します。このシナリオを実行するための具体的な手順については、Amazon Cognito のドキュメントを参照してください。

1. (オプション) Login with Amazon、Facebook、Google、または他の任意の OpenID Connect (OIDC) 互換 IdP で開発者としてサインアップし、プロバイダーで 1 つ以上のアプリを設定します。Amazon Cognito ではユーザーの認証されていない (ゲスト) アクセスがサポートされているので、この手順はオプションです。

2. AWS Management Console の Amazon Cognito に移動します。Amazon Cognito ウィザードを使用して ID プールを作成します。これは、アプリのために Amazon Cognito がエンドユーザー ID を整理しておくために使用するコンテナです。ID プールは、アプリ間で共有できます。ID プールをセットアップすると、Amazon Cognito ユーザーのアクセス許可を定義する 1 つまたは 2 つの IAM ロールが Amazon Cognito によって作成されます (1 つは認証された ID 用、2 つ目は認証されていない「ゲスト」ID 用)。

3. AWS Amplify をアプリと統合して、Amazon Cognito の使用に必要なファイルをインポートします。

4. ID プールの ID、AWS アカウント 番号、および ID プールに関連付けたロールの Amazon リソースネーム (ARN) を渡して、Amazon Cognito 認証情報プロバイダーのインスタンスを作成します。AWS Management Console の Amazon Cognito ウィザードによって、作業の開始に役立つサンプルコードが提供されます。

5. アプリが AWS リソースにアクセスするときに、認証情報プロバイダーインスタンスをクライアントオブジェクトに渡します。このオブジェクトが一時的なセキュリティ認証情報をクライアントに渡します。認証情報のアクセス権限は、前に定義したロールに基づいています。

詳細については、次を参照してください:

• AWS Amplify Framework Documentation に (Android) でサインインします。

• AWS Amplify Framework Documentation に (iOS) でサインインします。

モバイルアプリの OIDC フェデレーション

最良の結果を得るには、ほぼすべての OIDC フェデレーションシナリオで Amazon Cognito を認証ブローカーとして使用してください。Amazon Cognito は使いやすく、匿名 (認証されていない) アクセスのような追加機能が用意されていて、複数のデバイスおよびプロバイダーにわたってユーザーデータが同期されます。ただし、手動で AssumeRoleWithWebIdentity API を呼び出すことによって OIDC フェデレーションを使用するアプリを既に作成してある場合は、それを使用し続けることができます。アプリは引き続き正常に動作します。

Amazon Cognito を使用せずに OIDC フェデレーションを使用するプロセスは、次の一般的な概要に従います。

1. 外部 ID プロバイダー (IdP) に開発者としてサインアップし、IdP に対してアプリを設定して、アプリの一意の ID を受け取ります。（異なる IdP は、このプロセスに異なる用語を使用します。この概要では、IdP を使用してアプリを識別するプロセスに configure (設定) という用語を使用します。） 各 IdP からはそれぞれ固有のアプリ ID を受け取るため、複数の IdP に対して同じアプリを設定した場合、アプリには複数のアプリ ID が与えられます。プロバイダーごとに複数のアプリを設定できます。

   以下の外部リンクで、一般的ないつくかの ID プロバイダー (IdP) の利用方法に関する情報を入手できます。

   • Login with Amazon 開発者センター

   • Facebook 開発者サイトの「アプリまたはウェブサイトに Facebook ログインを追加する」

   • Google 開発者サイトの「ログインでの OAuth 2.0 の使用 (OpenID Connect) 」

   重要

   Google、Facebook、または Amazon Cognito の OIDC IDプロバイダーを使用する場合は、AWS Management Console に個別の IAM ID プロバイダーを作成しないでください。AWS にはこれらの OIDC IDプロバイダーが組み込まれており、使用できます。次の手順をスキップして、ID プロバイダーを使用して新しいロールの作成に直接移動します。

2. OIDC と互換性のある Google、Facebook、または Amazon Cognito 以外の IdP を使用する場合は、IAM ID プロバイダーのエンティティを作成します。

3. IAM で、1 つ以上のロールを作成します。ロールごとに、だれがそのロールを引き受けることができるか（信頼ポリシー）、アプリのユーザーがどのアクセス権限を持つか（アクセス権限ポリシー）を定義します。通常は、アプリがサポートする IdP ごとに 1 つのロールを作成します。たとえば、ユーザーが Login with Amazon を使用してサインインするアプリで想定されるロール、ユーザーが Facebook を使用してサインインする同じアプリの 2 つ目のロール、およびユーザーが Google を使用してサインインするアプリの 3 つ目のロールを作成します。信頼関係の確立用に、IdP (Amazon.com など) を Principal (信頼されるエンティティ) として指定し、IdP 提供のアプリ ID と一致する Condition を含めます。異なるプロバイダーのロールの例は、サードパーティー ID プロバイダー (フェデレーション) 用のロールを作成するで説明されています。

4. アプリケーションで、IdP に対してユーザーを認証します。この具体的な方法は、どの IdP を使用しているか (Login with Amazon、Facebook、または Google)、どのプラットフォームでアプリを実行しているかの両方によって変わります。たとえば、Android アプリと iOS アプリや JavaScript ベースのウェブアプリとでは、認証方法が異なることがあります。

   一般的に、ユーザーがまだサインインしていない場合、IdP はサインインページを表示するように対処します。IdP はユーザーを認証した後、ユーザーに関する情報と共に認証トークンをアプリに返します。含まれる情報は、IdP が公開する情報と、ユーザーが共有する情報によって異なります。この情報はアプリで利用できます。

5. アプリで、アプリで、AssumeRoleWithWebIdentity アクションを署名なしで呼び出して、一時的なセキュリティクレデンシャルをリクエストします。リクエストでは、IdP の認証トークンを渡し、その IdP 用に作成した IAM ロールの Amazon リソースネーム (ARN) を指定します。AWS は、トークンが信頼されていて有効であることを確認します。確認できた場合、リクエストで指定したロールのアクセス許可が割り当てられた一時的セキュリティ認証情報をアプリに返します。応答には、IdP がユーザーに関連付けた一意のユーザー ID など、ユーザーに関する IdP からのメタデータも含まれます。

6. AssumeRoleWithWebIdentity レスポンスからの一時的セキュリティ認証情報を使用して、アプリから AWS API オペレーションへの署名付きリクエストを行います。IdP からのユーザー ID 情報は、アプリ内のユーザーを区別できます。例えば、プレフィックスまたはサフィックスとしてユーザー ID を含む Amazon S3 フォルダにオブジェクトを配置できます。これにより、そのフォルダをロックするアクセス制御ポリシーを作成して、その ID を持つユーザーに対してのみフォルダへのアクセスを許可できます。詳細については、「AWS STS フェデレーティッドユーザーセッションプリンシパル」を参照してください。

7. アプリで一時的なセキュリティ認証情報がキャッシュに格納されるようにすることで、アプリから AWS へのリクエストがあるたびに、新しい証明書を取得する必要がなくなります。デフォルトで、認証情報は 1 時間有効です。認証情報が失効すると (または失効前に)、AssumeRoleWithWebIdentity を呼び出して新しい 1 組の一時的なセキュリティ認証情報を取得します。IdP とそのトークンの管理方法によっては、AssumeRoleWithWebIdentity を新しく呼び出す前に、IdP のトークンを更新する必要があります。IdP のトークンも通常は一定期間後に失効するためです。AWS SDK for iOS または AWS SDK for Android を使用する場合は、AmazonSTSCredentialsProvider アクションを使用できます。このアクションは IAM の一時的な認証情報を管理し、必要に応じて更新します。