【第13回】Amazon Cognito + Spring Sercurityを使ったOAuth2 Loginの実装(2)¶
前回は、現在の実装状況や今後実現するOAuth2 Loginをベースとしたアーキテクチャを、以下のイメージのように整理しました。 今回以降は、OAuth2 Loginを実現するための認証・認可サーバとなるAmazon Cognitoについて概説し、環境を構築していきます。
Amazon Cognitoの概要¶
Amazon CognitoはAWSを提供する認証・認可機能を提供するサービスです。 主要な機能はユーザディレクトリ(ユーザ情報データベース)機能を提供する「ユーザプール」と、 認証されたユーザやGoogle、Apple、Facebookなどサードパーティプロバイダで認証されたユーザに、AWSサービスへアクセスするための認可を提供する「IDプール」機能に大別されます。
ユーザプールの主要な機能は以下の通りです。
| 機能 | 説明 |
| ユーザデータベース管理 | ユーザ属性を定義し、ユーザ情報を管理できます。パスワードポリシーなどを定義してルール化や、電話番号・Emailの認証機能をサポートします。 |
| サインアップ・サインイン | ユーザを作成したり、自身にサインアップさせたりすることができます。登録後はHostedUIを用いたサインイン機能をサポートします。サインアップ・サインイン機能については環境構築上重要なため、次節詳細に解説します。 |
| 多認証要素(Multi Factor Authentication : MFA) | EmailやスマートフォンのSMSを使った複数の認証を利用することができます。 |
| サードパーティプロバイダ連携 | 他のソーシャルメディアをはじめとしたサードパーティ認証プロバイダと連携し、ユーザ情報管理ができます。 |
| AWSサービス連携 | Amazon API GatewayやLambdaなどのサービスと連携し、認証を行うオーソライザ機能を持っています。 |
また、IDプールでは認証されたユーザに対して発行されたトークンを検証して、AWSサービスにアクセス可能な一時クレデンシャルを発行できます。
ユーザプールの環境構築¶
それでは、Cognitoを使ってユーザプールおよびIDプール、加えてOIDCプロバイダとしてOAuth2 Loginが可能な設定を進めましょう。 手順はコンソールから設定する方法とCloudFormationを使って構築する2種類あり、双方取り扱いますが、本連載では、アプリケーションから設定値をスタック経由で参照できる CloudFormationを使う方法を推奨します。ただし、まず設定内容の説明のため、今回は先にコンソールからの構築手順を解説します。
AWSコンソール上で Amazon Cognitoサービスから、「ユーザプールの管理」>「ユーザープールを作成する」を選択してください。
以下の設定内容に従って、ユーザープールの定義を行います。
| 設定内容 | 説明 |
| プール名 | ユーザプール名の名称を入力します。 |
| ユーザ名 | ユーザ名ではサインイン時の識別子(ログインID)に関する設定を行います。ここでは、検証済みの(ユーザから応答があった)メールを許可する設定を追加します。 |
| Eメールアドレスおよび電話番号 | Eメールか電話番号自体をユーザ名とするオプションを設定します。本連載では、ユーザ名を「taro.mynavi」などで設定したいのでここでは設定しません。 |
| (推奨)小文字と大文字を区別しない | ユーザ名で英大文字と小文字を区別するか選択します。ここでは区別する設定を行います。 |
| 必須の標準属性 | ユーザープール(ユーザディレクトリ)として設定するユーザ属性を定義します。ここでは、「苗字」と「名前」を選択しておきます。 |
| カスタム属性 | ユーザープール(ユーザディレクトリ)として設定するカスタムのユーザ属性を定義します。ここでは、「ログインID」と「管理者か否かを表す属性」を作成しておきます。 |
| パスワードポリシー | パスワードのルールをポリシーとして設定します。ここでは簡単のために緩い条件を設定していますが、実際はパスワード要件に沿ったものを設定するようにしてください。 |
| 自己サインアップ | ユーザ自身でサインアップを許可するか、管理者のみにユーザ作成を許可するか選択します。ここではユーザにも自己サインアップを許可する設定を行います。 |
| 有効期限 | ユーザ作成時に有効な一時パスワードの有効期限を設定します。これを過ぎるとユーザを作り直す必要があります。ここではデフォルトの7日のままで設定しておきます。 |
| 多認証要素(MFA)設定 | サインアップ・サインイン時の認証方法で、Eメールおよび電話番号を使用したSMSを多認証要素として設定します。ここではなしに設定します。 |
| アカウント回復方法設定 | ユーザがパスワードを忘れた際の、パスワードリセット方法に対する設定を行います。ここでは「使用可能な場合は E メール、それ以外の場合は電話。ただし、MFA にも使用している場合、電話でパスワードをリセットすることは許可しません」を設定します。 |
| 検証時に確認する属性 | サインアップ時やパスワードリセット時の確認方法を設定します。ここではEメールを選択します。 |
| SMSロール名 | SMSを発信するためのロールを作成するためロール名を入力します。ここではデフォルトのままで設定しておきます。 |
| Eメールアドレスのカスタマイズ | メールをユーザに発信する際の設定を行います。発信できるリージョンは「米国東部(バージニア)」などに限られますが、検証時に使われるメール送信の発出元なので、環境構築しているリージョンと異なっていても問題ありません。その他、送信元として表示されるメール設定やリプライ用のメール設定なども可能です。 ここではデフォルトのままで設定します。 |
| SESによるメール発信設定 | 大幅な数のユーザ追加が見込まれるようであれば、より大規模なメール発信が可能なSESによるメール設定を行います。ここではCognitoのままで設定しておきます。 |
| Eメール検証メッセージ設定 | 検証メールの内容をカスタマイズします。ここではデフォルトのままで設定しておきます。 |
| ユーザ招待メッセージ設定 | 招待メールおよび招待メッセージの内容をカスタマイズします。ここではデフォルトのままで設定しておきます。 |
| タグ設定 | Cognitoで作成するリソースにタグを付与します。ここでは何も設定は行いません。 |
| ユーザデバイス記憶設定 | 一度ログインが完了したブラウザの情報を通じてログイン状態を継続する、俗にいうRemembermeサービス設定です。ここでは、設定は行いません。 |
| アプリクライアント名 | Cognitoへアクセスするアプリケーションクライアントの設定を行います。本連載では、現状フロントエンドサブネットに配置したWebアプリケーションが相当します。ここではクライアントの名称を設定します。 |
| トークンの有効期限を更新 | リフレッシュトークンの有効期限の設定を行います。ここではデフォルトの30日に設定します。 |
| アクセストークンの有効期限を更新 | アクセストークンの有効期限の設定を行います。ここではデフォルトの60分に設定します。 |
| IDトークンの有効期限を更新 | IDトークンの有効期限の設定を行います。ここではデフォルトの60分に設定します。 |
| クライアントシークレットの生成 | アクセスしてくるアプリケーションのパスワードに相当するクライアントシークレットを生成します。これは、一般的にサーバサイドでトークンを授受する際に必要なパラメータとなります。 JavaScriptやモバイルアプリケーションなどのユーザ側に渡ってしまう可能性がある環境では、クライアントシークレットを渡さずに実現しますが、 ここでWebアプリケーションはサーバサイド側に配置されるのでクライアントシークレットを生成しておきます。 |
| 認証フローの設定 | ここでの認証フローとはOAuth2による認証フローではなく、ユーザサインアップ時のユーザ認証フローのことを指します。 ここでは、サーバサイドでCLIやSDKを使ってパスワード認証を有効可能にする「認証用の管理 API のユーザー名パスワード認証を有効にする (ALLOW_ADMIN_USER_PASSWORD_AUTH)」および、 「更新トークンベースの認証を有効にする (ALLOW_REFRESH_TOKEN_AUTH)」を選択しておきます。なお、「Lambda トリガーベースのカスタム認証を有効にする (ALLOW_CUSTOM_AUTH)」は LambdaでCognitoオーソライザーを行うときに利用します。「ユーザー名パスワードベースの認証を有効にする (ALLOW_USER_PASSWORD_AUTH)」および 「SRP (セキュアリモートパスワード) プロトコルベースの認証を有効にする (ALLOW_USER_SRP_AUTH)」はいずれも、JavaScriptやモバイルアプリケーションなどから ユーザ名パスワード認証を行うAPIを実行する場合に利用するオプションですが、特別な理由がない限り、セキュアパラメータやソルトを使ってより安全性を高めたSRPプロトコルベースの認証を選択した方が良いでしょう。 詳細は クライアント側の認証フロー も 参考にしてください。 |
| セキュリティ設定(ユーザ存在エラー) | ユーザが存在しない時の応答エラーを隠蔽したメッセージへとカスタマイズするオプションです。デフォルトのままで設定しておきます。 |
| トリガー設定 | ユーザプールにおける様々なイベント発生時にLambda関数を実行したい場合の設定オプションです。デフォルトのままで設定しておきます。 |
今回は、Amazon Cognitoの概要を説明し、ユーザプールの設定方法について説明しました。 次回以降は、このユーザプールの構築の中で作成したアプリクライアント定義にOAuth2 Loginとして必要な設定を行い、続いてIDプールを作成していきます。
著者紹介¶
川畑 光平(KAWABATA Kohei) - NTTデータ エグゼクティブ ITスペシャリスト ソフトウェアアーキテクト・デジタルテクノロジーストラテジスト(クラウド)
金融機関システム業務アプリケーション開発・システム基盤担当、ソフトウェア開発自動化関連の研究開発を経て、デジタル技術関連の研究開発・推進に従事。
Red Hat Certified Engineer、Pivotal Certified Spring Professional、AWS Certified Solutions Architect Professional等の資格を持ち、アプリケーション基盤・クラウドなど様々な開発プロジェクト支援にも携わる。
AWS Top Engineers & Ambassadors 選出。
本連載記事の内容に対するご意見・ご質問は Facebook まで。