Amazon CognitoとSpring Sercurityを使ったOAuth2 Loginの実装（1）- 現状の実装状況と目指すかたち

前回までの解説では、バックエンドに配置したマイクロサービスとフロントエンドに配置したWebアプリケーションを想定して実装してきました（下図参照）。

フロントエンドのWebアプリケーションについては、バックエンドにあるユーザーサービスによって取得した認証情報(IDとパスワード)で保護し、AWS X-Rayを使ってそれらを呼び出して関係を可視化する実装方法を解説しました。

しかし、この認証方式はSpring Securityの理解を深めるために採用したもので、本連載で最終的に目指すアーキテクチャのかたちではありません。また、前回までの実装の説明では、以下のようにローカル環境で構築したアプリケーションの実装例しか示していませんでした。

そこで、途中経過ではありますが、現在の実装の状況と、最終的に目指すかたちを改めて整理してみましょう。

まず、現状のアプリケーションの実装状況は上のイメージ通りですが、X-RayやDynamoDBといったリージョンサービスをローカル環境から利用しています。いくつかのサービスはCloudFormationで構築し、CloudFormationスタックからサービスエンドポイントなどの情報をローカル環境からも参照して、ローカル環境から各サービスにアクセスしています。

バックエンドマイクロサービスがアクセスするデータベースは、現状HSQLを使ったインメモリデータベースで代替しています。ただし、次節以降解説していくOAuth2 Loginとバックエンドマイクロサービスをアクセストークンで保護する実装が完了すれば、AWS環境へ移行する手順を解説する予定です。というのも、以降の解説や設定内容は、複雑で間違えやすいため、極力ローカルの統合開発環境などを使ってデバッグしやすい環境を整えて進めていくほうが良いからです。

次回以降もローカル環境での実装が続きますが、下記のようなAWS環境にあるアーキテクチャを想定しています。

次節以降で取り上げるOAuth2 Loginの解説のために、いったん最終的に構築するアーキテクチャイメージを切り取った、上記の図のスコープで解説を進めます。

なお、第2回でも説明した通り、最終的には以下のようになります。クラウドネイティブなマイクロサービスのアーキテクチャでは、段階的にクラウド環境と組み合わせてアプリケーション環境を構築していく手法を取りやすいので、小さな開発スコープで進めていくのが良い方法です。

OAuth2 Loginとは何か？

本連載では、OAuth2 Loginを「OAuth2/OpenIDConnect(OIDC)で規定されたプロトコル(OIDCはOAuth2を拡張して認証まで広げたプロトコル)を用いて、アプリケーションへログインさせる仕組み」と定義します。

これは、第2回でも解説した、認可コードグラントフローによるIDトークンや、アクセストークンを取得するフローそのものを指しています。一言で説明すると、最近のさまざまなWebサイトでよく見掛ける「XXXX(GoogleやFacebookアカウントなど)でログイン」がわかりやすいですが、ソーシャルログインやOAuth認証など、いくつか類似する紛らわしい語があるので、明確に区別しておきます。

ソーシャルログイン

Google、Facebook、TwitterやLINEをはじめとしたSNSが保持するID／パスワードなどを用いて認証を行い、それによって払い出されたトークンによって、別のアプリケーションへのアクセスを許可する仕組みです。OAuth2 Loginにはソーシャルメディアのみではなく、Amazon/AWSやApple、GitHubなどに加え、商用サービスとして提供されるOIDCプロバイダや、自前で構築したOIDC準拠のOSSサーバなども含んだ意味で利用します。

OAuth認証

通常、OAuthは認可のためのプロトコルであり、認証(そのユーザーを正当なものとして認める処理)とは異なります。OAuth2 LoginにおけるOAuth認証は、あくまで正当に正しく認証されたことを前提として取得されたトークンを使用してログイン処理を代替するものであって、OAuth2プロトコル(アクセストークン)を使って認証するものではありません。

OAuth認証は、インプリシットフローなど認可コードグラントフロー以外のものを利用した中で不適切な実装を行うと、ほかのサーバで利用されるアクセストークンを流出させる可能性を高めてしまいます。そのため、基本的には、OIDCプロトコルに基づいて、IDトークンやアクセストークンを取得することが必要です。

なお、払い出されるアクセストークンは合鍵のようなものであり、例えば、その合鍵をもってAPIアクセスしたリクエストが、必ずしもそれを利用可能な正当なユーザーとは限らない可能性に注意してください(アクセストークンを正当に取得したユーザーであっても、全てのユーザーがそのアクセストークンだけで保護されたAPIを実行できてしまうため)。

一方、OIDCにより払い出されるIDトークンは偽造不可能な名前付きの合鍵であり、サービス利用の権限をより細かく絞ることが可能です。

本連載で実現する認証認可方式

さて、第2回で、以下のような認可コードグラントフローを示しました。そちらで解説した通り、OAuth2 Loginを使用して、OIDCプロバイダ(認可サーバ)からトークンを取得し、フロントエンドアプリケーションへのログインや、マイクロサービスへのアクセス制御に利用するというのが、本連載で実現する認証認可方式のアイデアでした。

このOAuth2 Loginのフローを先に示した想定アーキテクチャ図に当てはめると、以下のようになります。便宜上、矢印をいくつか省略していますが、上記のフロー図の中で対応する番号は合わせています。

なお、第2回で記載した認可コードグラントフローには事前に記載できなかったものがあります。それは、バックエンドのマイクロサービスからCognitoへ出ている「(0)トークンデコードのための公開鍵を取得」です。

これは、事前にマイクロサービスが送信されてきたトークンを復号化するためのキーを、発行元の認可サーバから取得しておく処理のことで、マイクロサービスのスケーラビリティを高めるための一助となります。

もちろん、要件によっては、リクエスト送信時点のトークンの有効性を確認するために 認可サーバなどへ問い合わせを行う必要があるケースもあります。しかし、少なくとも送信されてきたトークンはJWT(JSON Web Token)形式で生成されるため、発行時点の有効性や偽造の有無などは 公開鍵の復号可否によってある程度担保されます^※。そのため、マイクロサービスを保護するための選択肢の有力なオプションの1つとして考えると良いでしょう。

※　JWTトークンの検証については、AWS公式Q&Aの「Amazon Cognito JSON ウェブトークンの署名をデコードして検証するにはどうすればよいですか?」も参考にしてください。

*　*　*

今回は、今後本連載で解説していくアーキテクチャや実装の目指す方向を整理し、マイクロサービスを保護するために導入するOAuth2 Loginについて説明しました。次回以降は、当環境のアプリケーションでOAuth2 Loginを実現するための認証／認可サーバとして利用するAmazon Cognitoについて説明し、環境を構築していきます。