AWS CognitoとOAuth2.0/OpenIDConnectの連携方法・ユースケースを紹介！外部認証プロバイダーを使用したAWS Cognito構築を検討している方は必見です😎

こんにちは！

AWS でアプリケーションの認証認可を構築する場合、AWS Cognito の利用は必須と言えます。しかしながら、AWS における認証・認可は、AWS Cognito , IAM STS をはじめとした様々なサービスが登場するせいか、なかなか理解しづらい部分でもあります。

本記事では、認証認可の概要から AWS Cognito を使用した外部 IDP サインインの方法について詳しく解説したいと思います。

想定する読者

• SPA への認証機能の導入を検討しているヒト
• 外部 ID プロバイダ – Cognito 連携のユースケースについて悩んでいるヒト

はじめに

まず、認証・認可の違いとそれぞれを目的とした技術についてご説明します。

OpenID Connectとは

OpenID Connect は、クライアントアプリからサインインを試みた人が本人であるかを確認する『認証』のためのプロトコルです。代表的な例としては、WEB アプリへの Google 認証や Faceboook 認証が該当します。

OpenID Connect のプロトコルを提供する認証サーバーは、クライアントにユーザー情報を提供するために署名済みの IDトークンをレスポンスし、クライアントはレスポンスされた署名済みの IDトークンによって認証状態を検証することが可能となります。

以下が OpenID Connect を提供している ID プロバイダ（以下、IDP）として挙げられます。

• Facebook
• Amazon
• Google
• Apple
• Salesforce
• Ping Identity
• Okta
• Microsoft Azure Active Directory (Azure AD)

OAuth2.0とは

OAuth2.0 は、認証されたユーザーがどのリソースにどのようなアクセス権限を持っているかを確認する『認可』のプロトコルとなります。

認可サーバーは、認証済みクライアントに特定のアクセス権限を与えるためにアクセストークンを発行します。アクセストークンは認証後に得ることができるトークンとなるため、AWS Cognito ユーザープールで認証⇨ AWS Cognito ID プールから認可トークンを取得といった流れとなります。（後述）

OpenID ConnectとOAuth2.0の違い

OpenID Connect は OAuth2.0 を拡張した仕様です。

OAuth2.0 が『認可』のみを取り扱うのに対し、OpenID Connect は『認証』・『認可』両方を取り扱うことができます。

アプリケーションへのセキュアなアクセス管理実現のためには、API への権限付与だけでなく、それを利用するクライアントの正当性を確認することが重要です。つまり一般的なアプリケーションでは『認可』だけでなく『認証』を提供することが必要（推奨）であり、Open ID Connect はいいとこ取りの最新のプロトコルとなります。

Cognito ユーザープールの外部 IDP への対応

Cognito ユーザープールのデフォルトで対応している IDP

まず、Cognito ユーザプールは、独自のユーザー認証もしくは外部 IDP によるサインインに基づいて、ユーザーディレクトリ（ユーザーごとのプロファイルのようなイメージ）を作成します。認証に成功したユーザーは作成されたユーザーディレクトリに基づいた ID トークン（認証トークン）を取得することが可能です。

外部サインインに成功したユーザーは、Cognito ユーザープールへの初回外部サイン時に作成されたユーザーディレクトリと IDP のユーザー情報が恒久的に紐付くため、外部サインインしたユーザーを AWS で一意のユーザーとして扱うことができます。

Coginito ユーザープールはデフォルト以下の外部サインインに対応しています。

• ソーシャル IDP（Facebook, google, Login with Amazon, Sign in With Apple）
• SAML2.0 をサポートするプロバイダ（ADFS, Shibbolethなど）
• OpenID Connectを サポートするプロバイダ（Salesforce, Ping Identityなど）

各 SNS 媒体に認証用のアプリケーションを事前に作成、連携用のトークン（LINE 認証アプリの場合チャンネル ID等）を AWS Cognito へ設定するだけで簡単に連携を行うことが可能です。AWS で外部 IDP によるサインインを実現されたい方はぜひチャレンジしてみてください。

デフォルトで認証機能を扱うための UI を提供

Cognito ユーザープールでは、標準で HostedUI という機能により外部 IDP との連携が可能なデフォルト認証画面を提供しています。これを使用することで、ログイン画面を別途実装する必要がなくなり、開発者は認証関連の UI 実装を一式行わなずに認証機能を構築することができます。（後述しますがデザインを自由にカスタムできない制約有…）

なお、2021年7月現在、HostedUI は以下のような英語版 UI のみ提供しており日本語には対応していないのでご注意下さい。

英語のみ対応していることや、自前の UI と比較してカスタマイズ性が低いことから、プロトタイプ開発やベータ版の導入といったケースでのみ HostedUI の利用が推奨されます。

CognitoID プールの外部 IDP への対応

Cognito IDプールによる外部 IDP 認証のユースケース

S3 バケットやその他の AWS リソースへのアクセスを、外部 IDP を使用して手軽に実現したい場合は、Cognito ID プールと外部 IDP のみで認可機構を構築することが可能です。

主なユースケースとしては以下になります。

• 認証したユーザーのプロフィールに対しカスタムをしない
• 認証用の共通サーバーが存在し、そこで認証機能の要件が完結している

基本的には Cognito ユーザープールと CognitoID プールを連携させることを推奨

Cognito ユーザープールを認証プロバイダーに設定することで以下のような、認証機能の拡張を実現することができます。

拡張項目	内容
強力なセキュリティ機能	MFA 認証や、アダプティブ認証（ログインデバイス情報等を基にリスクに応じMFA 要求・ブロック）機能を実現
ログの監視・サインアップフローのカスタム	CloudTrail による API 呼び出しのログ記録や、Lambda を連携したサインインフローの変更によるユーザーエクスペリエンスの改善など
他サービスとの連携	サードパーティアプリの OAuth2.0 認可機能への連携

開発時は、積極的に Cognito ユーザープールと CognitoID プールの組み合わせを利用しましょう。

CognitoID プールの動作概略

CognitoID プールは、認証プロバイダからログインユーザー情報を受け取り、ユーザーに応じて STS により AWS 一時クレデンシャルキーを発行します。これによりクライアントは許可された AWS リソースにアクセスできます。

CognitoID プールによる認可の前段では、認証プロバイダとして Cognito ユーザープールを利用するケースが多いですが、ユーザープールを使わず外部 IDP 認証のみで実装することも可能です。

Cognito ユーザープールと Cognito ID プールは、それぞれ全く異なる役割・機能を提供しますので、しっかりとユースケースに応じて使い分けましょう。

まとめ

AWS Cognito を利用することで、充実した認証・認可機能を簡単に構築することができます。

様々な AWS サービスを連携してさらに柔軟性のある認可を構築することもできるので、AWS を利用するなら積極的に使っていきたいサービスですね。私たちはAWS アプリケーションへの認証機能構築に必ずと言えるほど AWS Cognito を使用します。

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