マイナビニュースマイナビ

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

【連載】

AWSで作るマイクロサービス

【第12回】Amazon CognitoとSpring Sercurityを使ったOAuth2 Loginの実装(1)- 現状の実装状況と目指すかたち

[2021/01/21 08:00]川畑 光平 ブックマーク ブックマーク

前回までの解説では、バックエンドに配置したマイクロサービスとフロントエンドに配置した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

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

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

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

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

* * *

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

著者紹介


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

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

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

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

※ 本記事は掲載時点の情報であり、最新のものとは異なる場合がございます。予めご了承ください。

一覧はこちら

連載目次

もっと知りたい!こちらもオススメ

【連載】マイクロサービス時代に活きるフレームワーク Spring WebFlux入門 [2] Spring WebFluxの要! リアクティブプログラミング入門

【連載】マイクロサービス時代に活きるフレームワーク Spring WebFlux入門 [2] Spring WebFluxの要! リアクティブプログラミング入門

今回は、Spring WebFluxを使う上で欠かせない要素である「リアクティブプログラミング」と「Reactor」について解説します。

関連リンク

この記事に興味を持ったら"いいね!"を Click
Facebook で TECH+ の人気記事をお届けします
注目の特集/連載
[解説動画] Googleアナリティクス分析&活用講座 - Webサイト改善の正しい考え方
Slackで始める新しいオフィス様式
Google Workspaceをビジネスで活用する
ニューノーマル時代のオウンドメディア戦略
ミッションステートメント
次世代YouTubeクリエイターの成長戦略
教えてカナコさん! これならわかるAI入門
AWSではじめる機械学習 ~サービスを知り、実装を学ぶ~
Kubernetes入門
SAFeでつくる「DXに強い組織」~企業の課題を解決する13のアプローチ~
AWSで作るマイクロサービス
マイナビニュース スペシャルセミナー 講演レポート/当日講演資料 まとめ
セキュリティアワード特設ページ

一覧はこちら

今注目のIT用語の意味を事典でチェック!

一覧はこちら

会員登録(無料)

ページの先頭に戻る