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

はじめに
よく使われる@authルールのパターン
複数の認証タイプの設定
終わりに

はじめに

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

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

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

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

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

オーナーベースの認証

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

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

type YourModel @model @auth(rules: [{ allow: owner }]) { ... }

1
2
3

type YourModel @model @auth(rules: [{ allow: owner }]) {
...
}
所有者は作成と削除ができ、他の人は更新と読み取りができます。

type YourModel @model @auth(rules: [{ allow: owner, operations: [create, delete]}]) { ... }

1
2
3
4

type YourModel @model @auth(rules: [{ allow: owner,
operations: [create, delete]}]) {
...
}

静的グループ認証

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

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

type YourModel @model @auth(rules: [{ allow: groups, groups: ["Admin"] }]) { ... }

1
2
3
4

type YourModel @model @auth(rules: [{ allow: groups,
groups: ["Admin"] }]) {
...
}

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

type YourModel @model @auth(rules: [{ allow: groups,
                                     groups: ["Admin"],
                                 operations: [create, delete] }]) {
...
}

type YourModel @model @auth(rules: [{ allow: groups,

groups: ["Admin"],

operations: [create, delete] }]) {

...

}

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

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

type YourModel @model @auth(rules: [{ allow: owner },
                                    { allow: groups, groups: ["Admin"]}]) {
...
}

type YourModel @model @auth(rules: [{ allow: owner },

{ allow: groups, groups: ["Admin"]}]) {

...

}

パブリックオーソライズ

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

type YourModel @model @auth(rules: [{ allow: public }]) { ... }

1
2
3

type YourModel @model @auth(rules: [{ allow: public }]) {
...
}
認証プロバイダはIAMで、すべてのデータはパブリックCRUDです。

type YourModel @model @auth(rules: [{ allow: public, provider: iam }]) { ... }

1
2
3

type YourModel @model @auth(rules: [{ allow: public, provider: iam }]) {
...
}

プライベートの認証

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

type YourModel @model @auth(rules: [{ allow: private }]) { ... }

1
2
3

type YourModel @model @auth(rules: [{ allow: private }]) {
...
}
IAM認証されたユーザーは、誰が作成したかに関わらず、すべての投稿をCRUDできます。ゲストユーザーはアクセスできません。

type YourModel @model @auth(rules: [{ allow: private, provider: iam }]) { ... }

1
2
3

type YourModel @model @auth(rules: [{ allow: private, provider: iam }]) {
...
}

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

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

type YourModel @model @auth(rules: [{ allow: owner,
                                   provider: oidc,
                              identityClaim: "sub" }]) {
...
}

type YourModel @model @auth(rules: [{ allow: owner,

provider: oidc,

identityClaim: "sub" }]) {

...

}

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

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

type YourModel @model @auth(rules: [{ allow: groups
                                   provider: oidc
                                     groups: ["Admin"]
                                 groupClaim: "https://myapp.com/claims/groups"
                                    }]) {
...
}

type YourModel @model @auth(rules: [{ allow: groups

provider: oidc

groups: ["Admin"]

groupClaim: "https://myapp.com/claims/groups"

}]) {

...

}

複数の認証タイプの設定

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

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

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

import Amplify, { AuthModeStrategyType } from 'aws-amplify';
import awsconfig from './aws-exports'; 

Amplify.configure({
  ...awsconfig,
  DataStore: {
    authModeStrategyType: AuthModeStrategyType.MULTI_AUTH
  }
})

import Amplify, { AuthModeStrategyType } from 'aws-amplify';

import awsconfig from './aws-exports';

Amplify.configure({

...awsconfig,

DataStore: {

authModeStrategyType: AuthModeStrategyType.MULTI_AUTH

}

})

この設定により、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のデフォルトの認証タイプを引き続き使用します。

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

type YourModel
  @model
  @auth(
        rules: [
            { allow: owner }
            { allow: public, provider: apiKey, operations: [read] }
        ]
    ) {
  ...
}

type YourModel

@model

@auth(

rules: [

{ allow: owner }

{ allow: public, provider: apiKey, operations: [read] }

]

) {

...

}

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

終わりに

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

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

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