[第15回] 認証ルールの設定

AWS Amplify

 

はじめに

 

皆さん。こんにちは! DreamHanksのエルムです。

今回は認証ルールの設定について説明していきます。

前回の記事は[第14回] データをクラウドに同期する簡単な方法です。

 

よく使われる@authルールのパターン

 

Amplifyでは、@authディレクティブを指定することで、タイプ上のデータを作成、読み取り、更新、削除するためのアクセス権を持つ個人やグループを制限することができます。

 

オーナーベースの認証

 

オーナーベースの認証でよく使われるパターンを以下に示します:

 

  • 作成/読み取り/更新/削除されたミューテーションは、所有者に非公開です。

     
  • 所有者は作成と削除ができ、他の人は更新と読み取りができます。

     

静的グループ認証

 

静的グループ認証でよく使われるパターンを以下に示します:

 

  • 管理者」グループに属するユーザーはCRUD(作成、読み取り、更新、削除)が可能で、その他のユーザーは何もアクセスできません。

     
  • Admin “グループに属するユーザーは、CRUD、その他のクエリやアップデートを行うことができます。

     

オーナーとスタティックグループの組み合わせ

 

  • ユーザーは自分のデータを持っていますが、Adminグループに属しているユーザーは、自分のデータとそのグループに属する人にアクセスできます。管理者グループのユーザーは、管理者グループに属さないユーザーに代わって変異を起こすことができます。

     

パブリックオーソライズ

 

  • 認証プロバイダはAPIキー、すべてのデータはパブリックCRUDです。

     
  • 認証プロバイダはIAMで、すべてのデータはパブリックCRUDです。

     

プライベートの認証

 

  • Cognitoユーザープールの認証を受けたユーザーは、誰が作成したかに関わらず、すべての投稿をCRUDすることができます。ゲストユーザーはアクセスできません。

     
  • IAM認証されたユーザーは、誰が作成したかに関わらず、すべての投稿をCRUDできます。ゲストユーザーはアクセスできません。

     

OIDCプロバイダーとのオーナーベースの認証

 

  • サードパーティのOIDCプロバイダーを利用して、オーナーベースの認証を実現します。 (例:Facebook、Googleなど…)。

     

 

OIDCプロバイダーによる静的グループ認証

 

  • groupClaimにカスタム値を使用して、サードパーティのOIDCプロバイダで静的なグループ認証を行います。

     

 

複数の認証タイプの設定

 

いくつかのユースケースでは、DataStoreで複数の認証タイプを使用したい場合があります。例えば、アプリでは、公開コンテンツにはAPI Keyを使用し、ユーザーがログインした後のパーソナライズされたコンテンツにはCognito User Poolを使用するといった具合です。

 

デフォルトでは、DataStoreはamplifyconfiguration.json/aws-exports.jsファイルで指定されたAPIのデフォルト認証タイプを使用します。 デフォルトの認証タイプを変更するには、amplify update apiを実行します。モデルの@authルールに関わらず、DataStoreを介して送信されるすべてのネットワーク・リクエストは、その認証タイプを使用します。

 

モデルの@authルールに基づいて、DataStoreが複数の認証タイプを使用できるようにするには、DataStoreの初期化時に “auth mode strategy “を設定します。

 

この設定により、DataStoreは各モデルの@authルールのプロバイダを使用してデータを同期させることができます。

 

複数の認証タイプの優先順

 

モデルに複数の@authルールがある場合、ルールは優先度によってランク付けされ(下記参照)、DataStoreは1つが成功する(または全てが失敗する)まで、それぞれの認証タイプで同期を試みます。

 

 Priority  allow: AuthStrategy         Provider
 1          owner          userPools
 2          owner          oidc
 3          group          userPools
 4          group          oidc
 5          private          userPools
 6          private          iam
 7          public          iam
 8          public          apiKey

 

認証されたユーザー・セッションがない場合、DataStoreはパブリック・ルールのみを試みます。

モデルに認証ルールが定義されていない場合、DataStoreはamplifyconfiguration.jsonのデフォルトの認証タイプを引き続き使用します。

 

複数の認証タイプを持つ例:

 

DataStoreは、認証されたユーザーがいる場合、データを同期する際に最初にオーナーベースの認証を使用しようとします。何らかの理由でそのリクエストが失敗した場合、DataStoreは公開認証で再度リクエストを試みます。認証されたユーザーがいない場合は、公開認証が使用されます。

 

終わりに

 

今回の記事は以上になります。

次回は [第16回] コンフリクトの解決を学びましょう。

ご覧いただきありがとうございます。

 

 

 

コメント