前回から、以下のイメージのようにOAuth2 Loginをベースとしたアーキテクチャを想定した環境構築を進めています。

構成図

前回は、OAuth2 Loginを実現するための認証／認可サーバとなるAmazon Cognitoについて概説し、ユーザープールをマネジメントコンソール上から構築しました。今回からは、OAuth2 Loginに必要なアプリクライアントの設定を行い、IDプールを構築していきます。

アプリクライアント／ドメインの設定

ユーザープールは前回作成したので、同時に作成されたアプリクライアントの定義にOAuth2 Loginに必要な設定を行います。

AWSコンソール上で Amazon Cognitoサービスから、「ユーザープールの管理」で前回作成したユーザープールを選択し、「アプリクライアントの設定」を選択して以下の要領で設定を行います。

設定

以下の設定内容に従って、アプリクライアントの設定を行います。

設定内容 説明
有効なIDプロバイダ プロバイダとして利用するユーザーディレクトリを選択します。唯一のオプションになりますが、Cognitoユーザープールを指定しておきます
コールバックURL アプリクライアントからリダイレクトされたCognitoで認証が完了した後、ブラウザが認可コードをCognitoから付与されて、アプリクライアントへ再びリダイレクトするURL(冒頭の図の5の箇所)を設定します。 次回以降、改めて解説しますが、Spring Securityで、このリダイレクトを受け入れるURLは「https://domain_name/context_path/login/oauth2/code/provider_name」形式です。今回は、ローカルで実行されるアプリケーション向けに「http://localhost:8080/frontend/login/oauth2/code/cognito」を設定します。なお、この設定値が正しく一致しなければ、正しく動作しません
サインアウトURL (Cognitoユーザープールの)サインアウト後にリダイレクトするアプリケーションクライアントのURLを設定します。ここではローカルで実行されるフロントエンドWebアプリケーションの「http://localhost:8080/frontend」を設定しておきます
許可されているOAuthフロー 認可コードグラントである「Authorization code grant」を設定します。なお、ほかの選択肢であるインプリシットグラントは 認可コードの代わりに直接アクセストークンを払い出す方式で、セキュリティ面で望ましくなく、クライアントクレデンシャルは用途が非常に限定された状況で用いられるオプションです。詳細はTERASOLUNAガイドライン「OAuth2.0のアーキテクチャ」も参考にしてください
許可されているOAuthスコープ OAuth 2.0では保護されたリソースに対するアクセスを制御する方法としてスコープという概念を使用しています。Cognitoはクライアントからの要求に対し、アクセストークンにスコープを含め、保護されたリソースに対するアクセス権（読み込み権限、書き込み権限など）を指定することができます。(要はアクセストークンが認可された操作に相当する権限です)。ここでは、OIDCのユーザークレイム(ユーザー情報)を含むIDトークンや、ユーザープールのAPIオペレーションが可能な権限、ユーザー情報プロファイルにアクセス可能なように、「openid」「aws.cognito.signin.user.admin」「profile」の3つを選択してください。詳細はAWS公式の開発ガイド「ユーザープールのアプリクライアントの設定」も参考にしてください

続いて、アプリクライアントからCognitoにリダイレクトされる際のドメインを設定します。ドメイン名から、有効なURLを作成してください。

URLを作成

IDプールの設定

引き続き、ユーザープールで発行されたトークンを検証するIDプールの作成を行います。AWSコンソール上でAmazon Cognitoサービスから、「IDプールの管理」→「IDプールを作成する」を選択してください。

以下の設定内容を入力します。

  • IDプール名：一意となるIDプール名
  • 認証プロバイダー／Cognito／ユーザープールID：前回作成したユーザープールのID
  • 認証プロバイダー／Cognito／アプリクライアントID：前回作成したアプリクライアントのID
URL作成

アクセス権限はデフォルトのままでかまいません。

アクセス権限

*　*　*

今回は、アプリクライアントおよびドメイン設定方法と、IDプールの作成について説明しました。このようにマネジメントコンソールを使って手動で設定を行っても良いですが、前回も前置きしたように、本連載では、アプリケーションから設定値をスタック経由で参照できるCloudFormationを使って環境構築する方法を推奨します。次回以降は、CloudFormationを使ってCognitoの環境を作成してみます。

著者紹介


川畑 光平(KAWABATA Kohei) - NTTデータ
エグゼクティブ ITスペシャリスト ソフトウェアアーキテクト・デジタルテクノロジーストラテジスト(クラウド)

金融機関システム業務アプリケーション開発・システム基盤担当、ソフトウェア開発自動化関連の研究開発を経て、デジタル技術関連の研究開発・推進に従事。

Red Hat Certified Engineer、Pivotal Certified Spring Professional、AWS Certified Solutions Architect Professional等の資格を持ち、アプリケーション基盤・クラウドなど様々な開発プロジェクト支援にも携わる。AWS Top Engineers & Ambassadors選出。

本連載の内容に対するご意見・ご質問は Facebook まで。