AppSyncの認証モード、IAM認証とCognitoユーザープールを比較してみた😎

こんにちは！

AppSync の認証モードにはいくつか種類がありますが、IAM 認証と Cognito ユーザープールは実際どう違うの？と思われたことはありませんでしょうか。

今回はそんな疑問を解消するべく記事を書きました！ぜひお付き合いください！

想定する読者

• AppSync に興味があるヒト
• AppSync の認証モードで IAM 認証を使いたいヒト
• AppSync の認証モードで Cognito ユーザープールを使いたいヒト
• AppSync について理解を深めたいヒト

はじめに

GraphQL のマネージドサービスである AppSync、認証に用いられる Cognito ユーザープールと IAM、これらを組み合わせたアーキテクチャは定番なものとなります。

今回は IAM と Cognito ユーザープール、この2つの似て非なる認証方式がどう違うのかを比較しながら解説していきたいと思います。

AppSync の認証モードについて

AppSync における「認証モード」とは、AppSync を操作するためにアプリケーションを認証する方法のことを指しています。

現在、AppSync では、API キー・IAM・OpenID Connect・Cognito ユーザープール、これら4つの認証方式が採用されています。なお、複数の認証方式を組み合わせることも可能です。

それでは順に IAM、Cognito ユーザープールについて解説していきます。

IAM での認証

IAM での認証はシンプルに、対象の AppSync を操作できる IAM ロールを付与しているリソースやユーザーであればクエリを実行するこができます。利用するには、GUI 画面で「認証モード」を IAM に設定します。

CloudFormation では以下のように設定します。

Resources:
 GraphQLApi:
    Type: AWS::AppSync::GraphQLApi
    Properties:
      AuthenticationType: AWS_IAM #required
      Name: AppSyncDemo #required

あとは、スキーマに認証モード @aws_iam を指定すれば利用が可能です。実際のスキーマは以下のような形になります。

input CreateInputUser {
	id: String!
	name: String!
}

type Mutation {
	createUser(input: CreateInputUser!): Test
		@aws_iam
}

type Query {
	getUser(id: ID!): Test
		@aws_iam
}

type Test @aws_iam {
	id: ID!
	name: String!
}

schema {
	query: Query
	mutation: Mutation
}

この状態になれば、IAM ロールを付与されている場合だけクエリが実行できるようになります。

Cognito ユーザープールを用いた認証方式との違いは、ユーザー作成やログインの必要がないため、とてもシンプルな操作権限の付与が可能となります。しかし IAM 認証方式だけを採用した認証ではあまりメリットを感じづらいでしょう。

ですので IAM 認証方式を用いる場合は、Cognito ユーザープールなどと組み合わせることで使いどころが広がっていくかと思います。

例えば、ログインできなかったユーザーに非認証ロールを付与する場合、非認証ユーザーの操作を制限した状態で AppSync にクエリを実行することも可能です。

ぜひ複数の認証方式を利用する際は、IAM 認証を検討してみましょう。

Cognito ユーザープール

Cognito ユーザープールでの認証は、ログインして発行されたトークンを用いてAppSync のクエリを実行します。GUI 画面では、以下のように設定します。

CloudFormation では以下のように設定します。

Resources:
 GraphQLApi:
    Type: AWS::AppSync::GraphQLApi
    Properties:
      AuthenticationType: AMAZON_COGNITO_USER_POOLS #required
      Name: AppSyncDemo #required
      UserPoolConfig:
        AppIdClientRegex: xxxxxxxxxxxxxxxxx
        AwsRegion: ap-northeast-1
        DefaultAction: ALLOW
        UserPoolId: xxxxxxxxxxxxxxxxx

パラメータ「UserPoolConfig」を記述することで設定が可能となります。

あとはスキーマに、@aws_cognito_user_pools を追記すれば認証が通るようになります。記述は IAM と同様です。

input CreateInputUser {
	id: String!
	name: String!
}

type Mutation {
	createUser(input: CreateInputUser!): Test
		@aws_cognito_user_pools
}

type Query {
	getUser(id: ID!): Test
		@aws_cognito_user_pools
}

type Test @aws_cognito_user_pools {
	id: ID!
	name: String!
}

schema {
	query: Query
	mutation: Mutation
}

これでログインしたユーザーのみがクエリを実行できるようになります。

IAM での認証との違いは、ログインが成功しなければ　AppSync を操作する一時的なロールが付与されないという点になります。

2つの違いはログインのプロセスを行うか否かですが、アプリのユーザー管理を提供する Cognito ユーザープールと、リソースにアクセスできる範囲などを制御できる IAM ロールは、目的に応じて使い分けることで認証のセキュリティを高めることができるでしょう。

また前述した通り、IAM と Cognito ユーザープールの認証方式を組み合わせて利用すれば、細かい認証のコントロールが可能となります。

API キーの認証方式だとキーの有効期限などがあるため、別の方法で認証したいと考えておられる方は、IAM や Cognito ユーザープールでの認証を考えてみても良いかと思います。

複数の認証方式を組み合わせてもよいので、適材適所で使っていきましょう！

関連記事

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

まとめ

認証方式の理解を増やしていくことによって、AppSync のセキュリティを今より高めることができるのかも知れません。成長中の AppSync ですので、認証関連のアップデートがこれから来るかもしれませんね。今後も楽しみです！

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

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