メニュー
AWS Identity and Access Management
ユーザーガイド

モバイルアプリへのウェブ ID フェデレーション API の使用

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

注記

ウェブ ID フェデレーションの仕組みを理解する一助として、Web Identity Federation Playground を利用できます。」は、インタラクティブなウェブサイトで、Login with Amazon、Facebook、または Google を介して認証を行い、一時的なセキュリティ認証情報を取得し、その認証情報を使用して AWS にリクエストを行うプロセスを体験できます。

Amazon Cognito なしでウェブ ID フェデレーションを使用するプロセスの概要は以下のとおりです。

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

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

    注記

    Amazon Cognito と Google は OIDC テクノロジに基づいていますが、IAM でそれらの ID プロバイダーのエンティティを作成する必要はありません。Amazon Cognito と Google のサポートは AWS に組み込まれています。

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

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

  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 への署名付きリクエストを実行します。ID プロバイダーからのユーザー ID を使用してアプリでユーザーを区別できます。たとえば、ユーザー ID をプレフィックスまたはサフィックスとして含む Amazon S3 フォルダーにオブジェクトを配置できます。これにより、そのフォルダーをロックするアクセス制御ポリシーを作成して、その ID を持つユーザーに対してのみフォルダーへのアクセスを許可できます。詳細については、このトピックで後述する「ウェブ ID フェデレーションを使用したユーザーの識別」を参照してください。

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