AppSyncで@authの認証方法を実装・検証してみた😎

こんにちは！

AppSync ではいくつかの認証方式がありますが、中でも Cognito ユーザープールを利用されるケースは多いかと思います。

今回はスキーマに @auth を記述することで細かいアクセス制御を実装・検証します。ぜひ最後までお読みください！

想定する読者

• AppSync の認証をコントロールしたいヒト
• AppSync の認証方式に Cognito ユーザープールを採用しているヒト
• AppSync に興味があるエンジニア

はじめに

そもそも@authとは？

@auth とは、API の認可をトップレベルで行うことができるディレクティブです。これを利用することで、細かなアクセスを実現することができます。具体的にはルールを定義することで、API のアクションに対する制限が可能になります。

今回は Amplify CLI を利用して、 Todo テンプレートを作成したものをいじりながら ＠auth の動作確認を行います。認証方式は Cognito ユーザープールを選択しました。

それでは実際に @auth を用いてどう認可をコントロールできるのかを見ていきましょう。

@auth の検証

それでは実際に @auth を利用してみましょう。まず Amplify CLI によって自動的に作成されたテンプレートの schema.graphql を以下のように変更します。（ AMPLIFY_PROJECT_NAME/backend/api/API_NAME 配下にあります）

type Todo @model 
  @auth(rules: [{ allow: owner }]) {
  id: ID! 
  name: String!
  owner: String
  description: String!
  updatedAt: AWSDateTime 
  createdAt: AWSDateTime 
}

上記の例は、所有者が作成したオブジェクトに対してすべてのアクション（create, get, list, update, delete）を行えるルールとなっております。そのほかのユーザーは create しかアクションを起こせません。

このようにルールを設定することで、様々なアクションに対して細かな制御ができるということです。以降は、いろんな方法でルールを定義してみましょう。

引数 operations

先程のルールに引数 operations を加えてルールを定義します。

type Todo @model 
  @auth(rules: [{ allow: owner, operations: [create, delete] }]) {
  id: ID! 
  name: String!
  owner: String
  description: String!
  updatedAt: AWSDateTime 
  createdAt: AWSDateTime 
}

上述のコードでは、所有者が作成したオブジェクトに対して削除することを許可しています。そのほかのユーザーには、削除以外のアクションであれば許可されている状態です。

ちなみに作成したオブジェクトの所有者は、下記のように作成されたDynamoDB テーブルの owner 列のところで判断しています。

では動作確認として、所有者でないユーザーがレコードを削除しようとするとどうなるのかを見てみましょう。

「sampleuser」が作成したレコードを「sampleuser2」が削除しようとしたら拒否されました。ではこのレコードの所有者である「sampleuser」が同じことをしてみます。

次はちゃんと削除されました。このように @auth のルールによってアクションに制約を設けることができます。

複数のルール

複数のルールを適用することもできます。下記のコードをご覧ください。

type Todo @model 
  @auth(rules: [
    { allow: owner },
    { allow: owner, ownerField: "editors", operations: [update, read] }
    { allow: groups, groups: ["Admin"] }
  ]) {
  id: ID! 
  name: String!
  owner: String
  editors: [String]!
  description: String!
  updatedAt: AWSDateTime 
  createdAt: AWSDateTime 
}

上記の場合のルールは、以下のようになります。

• 所有者が作成したオブジェクトに対しての操作は全許可
• 編集者( editors ) のユーザーはオブジェクトの所有者でなくても更新と読み取りが可能
• Admin グループであれば全ての操作が可能

試しに「sampleuser」が作成したレコードを編集者( editors )である「sampleuser2」が更新してみましょう。

上記の通り、更新することができます。

次に Admin グループのユーザーとそうでないユーザーで動作を確認してみます。「sampleuser2」は Admin グループのメンバーですが、「sampleuser3」はAdmin グループではありません。この状態でレコードを削除してみます。

このように事前に定義したスキーマに複数のルールを設けることで、指定通りのアクセス制御が可能となります。

ほかにも様々なことが @auth でできるので、ぜひ試してみてください！そしてAmplify はアップデートが早いので、これからもチェックしていきましょう！

関連記事

• Cognitoユーザープールグループの扱い方・IAMロールについてを解説します😎
• これから始めるAppSync開発！AppSyncとGraphQL開発手法をCTOが解説します😎
• AppSyncを理解するためにCloudFormationでの構成を深掘りしてみた🚀

まとめ

スキーマの定義に @auth ディレクティブを加えることで自動的にアクセス制御ができるところはとても便利ですね。活用できる場が多そうです。

このブログでは、GraphQL や GraphQL のマネージドサービスである AWS AppSync の記事をどんどん公開しておりますので、ご興味のある方はほかの記事もご覧いただければと思います。

AppSync に関する開発は、お気軽にお問い合わせください。