モバイルアプリへのウェブ ID フェデレーション API オペレーションの使用
最良の結果を得るには、ほぼすべてのウェブ ID フェデレーションシナリオで Amazon Cognito を認証ブローカーとして使用してください。Amazon Cognito は使いやすく、匿名 (認証されていない) アクセスのような追加機能が用意されていて、複数のデバイスおよびプロバイダーにわたってユーザーデータが同期されます。ただし、手動で AssumeRoleWithWebIdentity
API を呼び出すことによってウェブ ID フェデレーションを使用するアプリを既に作成してある場合は、それを使用し続けることができ、アプリは引き続き正常に動作します。
注記
ウェブ ID フェデレーションの仕組みを理解する一助として、Web Identity Federation Playground
Amazon Cognito を使用せずに WebID フェデレーションを使用するプロセスは、次の一般的な概要に従います。
-
外部 ID プロバイダー (IdP) に開発者としてサインアップし、IdP に対してアプリを設定して、アプリの一意の ID を受け取ります。(異なる IdP は、このプロセスに異なる用語を使用します。この概要では、IdP を使用してアプリを識別するプロセスに configure (設定) という用語を使用します。) 各 IdP からはそれぞれ固有のアプリ ID を受け取るため、複数の IdP に対して同じアプリを設定した場合、アプリには複数のアプリ ID が与えられます。プロバイダーごとに複数のアプリを設定できます。
以下の外部リンクで、一般的ないつくかの ID プロバイダー (IdP) の利用方法に関する情報を入手できます。
-
Facebook 開発者サイトの「アプリまたはウェブサイトに Facebook ログインを追加する
」 -
Google 開発者サイトの「ログインでの OAuth 2.0 の使用 (OpenID Connect)
」
重要
Google、Facebook、または Amazon Cognito の OIDC IDプロバイダーを使用する場合は、AWS Management Console に個別の IAM ID プロバイダーを作成しないでください。AWS にはこれらの OIDC IDプロバイダーが組み込まれており、使用できます。次の手順をスキップして、ID プロバイダーを使用して新しいロールの作成に直接移動します。
-
OIDC と互換性のある Google、Facebook、または Amazon Cognito 以外の IdP を使用する場合は、IAM ID プロバイダーのエンティティを作成します。
-
IAM で、1 つ以上のロールを作成します。ロールごとに、だれがそのロールを引き受けることができるか(信頼ポリシー)、アプリのユーザーがどのアクセス権限を持つか(アクセス権限ポリシー)を定義します。通常は、アプリがサポートする IdP ごとに 1 つのロールを作成します。たとえば、ユーザーが Login with Amazon を使用してサインインするアプリで想定されるロール、ユーザーが Facebook を使用してサインインする同じアプリの 2 つ目のロール、およびユーザーが Google を使用してサインインするアプリの 3 つ目のロールを作成します。信頼関係の確立用に、IdP (Amazon.com など) を
Principal
(信頼されるエンティティ) として指定し、IdP 提供のアプリ ID と一致するCondition
を含めます。異なるプロバイダーのロールの例は、サードパーティー ID プロバイダー (フェデレーション) 用のロールの作成で説明されています。 -
アプリケーションで、IdP に対してユーザーを認証します。この具体的な方法は、どの IdP を使用しているか (Login with Amazon、Facebook、または Google)、どのプラットフォームでアプリを実行しているかの両方によって変わります。たとえば、Android アプリと iOS アプリや JavaScript ベースのウェブアプリとでは、認証方法が異なることがあります。
一般的に、ユーザーがまだサインインしていない場合、IdP はサインインページを表示するように対処します。IdP はユーザーを認証した後、ユーザーに関する情報と共に認証トークンをアプリに返します。含まれる情報は、IdP が公開する情報と、ユーザーが共有する情報によって異なります。この情報はアプリで利用できます。
-
アプリで、アプリで、
AssumeRoleWithWebIdentity
アクションを署名なしで呼び出して、一時的なセキュリティクレデンシャルをリクエストします。リクエストでは、IdP の認証トークンを渡し、その IdP 用に作成した IAM ロールの Amazon リソースネーム (ARN) を指定します。AWS は、トークンが信頼されていて有効であることを確認します。確認できた場合、リクエストで指定したロールのアクセス許可が割り当てられた一時的セキュリティ認証情報をアプリに返します。応答には、IdP がユーザーに関連付けた一意のユーザー ID など、ユーザーに関する IdP からのメタデータも含まれます。 -
AssumeRoleWithWebIdentity
レスポンスからの一時的セキュリティ認証情報を使用して、アプリから AWS API オペレーションへの署名付きリクエストを行います。IdP からのユーザー ID を使用してアプリでユーザーを区別できます—たとえば、ユーザー ID をプレフィックスまたはサフィックスとして含む Amazon S3 フォルダにオブジェクトを配置できます。これにより、そのフォルダをロックするアクセス制御ポリシーを作成して、その ID を持つユーザーに対してのみフォルダへのアクセスを許可できます。詳細については、このトピックで後述する「ウェブ ID フェデレーションを使用したユーザーの識別」を参照してください。 -
アプリで一時的なセキュリティ認証情報がキャッシュに格納されるようにすることで、アプリから AWS へのリクエストがあるたびに、新しい証明書を取得する必要がなくなります。デフォルトで、認証情報は 1 時間有効です。認証情報が失効すると (または失効前に)、
AssumeRoleWithWebIdentity
を呼び出して新しい 1 組の一時的なセキュリティ認証情報を取得します。IdP とそのトークンの管理方法によっては、AssumeRoleWithWebIdentity
を新しく呼び出す前に、IdP のトークンを更新する必要があります。IdP のトークンも通常は一定期間後に失効するためです。AWS SDK for iOS または AWS SDK for Android を使用する場合は、AmazonSTSCredentialsProviderアクションを使用できます。このアクションは IAM の一時的な認証情報を管理し、必要に応じて更新します。