実装していくアーキテクチャの概要

前回はマイクロサービスアーキテクチャのメリットや導入で課題になりがちな検討項目、マイクロサービスアプリケーションを構築するにあたって、AWSがサポートする主なサービスを紹介しました。

今回からは、AWS上でマイクロサービスアプリケーションを構築するための具体的なアーキテクチャの概要と、そのアーキテクチャを実現する上で難しいハードルの一つとなる、認証／認可処理の全体像や考え方を解説していきます。

前回も説明した通り、近年ではWebアプリケーションやモバイル、運用端末といったマルチクライアントに加え、サードパーティ製のサービスに利用されることも想定して、ビジネスロジックを切り出し、マイクロサービスとしてAPI化することを検討するケースが増えつつあります。

一例としては、「オープンAPI」に端を発し、金融業界で標準仕様策定が進められている「オープンバンキング」や「FAPI(Financial-grade API)」に則ったAPIの公開が挙げられます。また、政府を中心としたパブリックセクターでも、営利目的／非営利目的を問わず、無償かつ二次利用可能なルールの下、機械判読に適したかたちで公共データを公開する「オープンデータ」の取り組みが推進されており、並行してこれをREST APIとして公開する動きも進んでいます。

エンタープライズ分野でも、有益なデータを持つ企業が、社内外向けにさまざまな目的でAPIを公開する事例が多くなってきました。既存システムで稼働しているアプリケーションをAPI化して不特定多数のユーザーやサービスに公開する場合、AWSのようにリクエスト量に応じてスケールアウト／縮退する機能を有するクラウドの利用が有力な選択肢として挙がります。

本連載では、上記のアーキテクチャに基づき、AWSのサービスを組み合わせてアプリケーションを構成／実装していく方法を紹介していきます。アーキテクチャの詳細は以下の通りです。

※　「re:Invent 2019」で発表されたAPI Gatewayの新機能「HTTP API」により、プライベートサブネットに配置したインターナルなALBへ直接リクエストをフォワードすることが可能になりました。

このような構成をとる場合、厳格なセキュリティの下、適切な権限に応じてAPI（マイクロサービス）にアクセスさせる仕組みが必要になります。APIを適切に保護し、第三者を含めて公開するためには、「OIDC(Open ID Connect)」や「OAuth 2.0」などの標準化されたセキュリティ仕様に準拠したミドルウェアやサービスを組み込んで、アーキテクチャを構成する必要があります。

OAuth 2.0/OIDC

OAuth 2.0やOIDCはそれぞれ1冊の本が書けてしまうほど、内容が深く重要なセキュリティ仕様です。いずれもRFC(Request for Comments:インターネット関連の標準技術)として、複数の仕様文書から構成されています。先にOAuth 2.0について解説しますが、詳細まで踏み込むと本連載の趣旨から大きく外れてしまうため、適宜ポイントを抜粋して進めます。詳細については、TERASOLUNAのガイドライン「9.9 OAuth」などである程度体系的にまとめられているので、必要に応じて参照してください。

OAuth 2.0とは、あるアプリケーションの一部の処理をWebサービスとして公開したい場合に、不特定多数のクライアントやサードパーティサービス(第三者製のアプリケーション)が、そのサービスを適切な権限に応じて利用できるようにするためのセキュリティに関する(認可)仕様です。

OAuth 2.0が定めている処理フローを具体的に書き出すと、以下のようになります。

1. 正当に認証されたクライアントに対して、「認可サーバ」と呼ばれるサーバが、アクセスする対象のWebサービスやアクセス元の情報、権限の情報をまとめた「アクセストークン」を発行
2. クライアントはターゲットとなるWebサービスへのリクエストにトークンを含めて送信
3. リクエストを受け付けるWebサービスは送信されてきたトークンを解析して、正当なリクエストかどうかを確認(し、問題なければ要求されたサービスを実行)

通常アプリケーションで実装されるフォーム認証／認可処理などと違い、サードパーティ製のアプリケーションに対して、ユーザーの認証情報を渡すことなく、権限に応じた処理の実行許可を与える(認可)点が特徴です。OAuth 2.0では、これを実現するために次の4つのロールを定義して、認可処理フローを仕様化しています。

各ロールの処理フローの大枠は、TERASOLUNAのガイドライン「OAuth 2.0 プロトコルフロー」を参照してください。OAuth 2.0では、クライアントのタイプ(Webサービスを利用したいアプリケーションの種別)に応じて、「グラントタイプ」というカテゴリーで4分類し、各々のタイプでアクセストークンの発行手法を仕様としてまとめています。ただし、アクセストークンを扱う際、特別な理由がなければ「認可コードグラント」というタイプの手法を用いるのが一般的です。ほかの手法は用途に応じて適切に利用しないと、セキュリティホールになり得ます。

一方、OIDCはOAuth 2.0の拡張としてまとめられた認証およびそのフローに関する仕様です。リソースオーナーがID／パスワードなどを用いて自身の認証を行うと、 クライアントとなるアプリケーションに対し、リソースオーナーの情報(User Claim：ユーザークレイム)をまとめたIDトークンが発行されます。OAuth 2.0と同じ要領で、認証／認可サーバが持つ「認可エンドポイント」「トークンエンドポイント」と呼ばれるURLにリクエストを送信することで、アクセストークンとIDトークンを同時に取得できる仕組みです。

OIDC／OAuthで保護するマイクロサービスアーキテクチャの全体像

前節で掲載したアーキテクチャ図にOAuth 2.0やOIDCのロールを当てはめると、以下のようになります（ロールとなり得る対象に、種別ごとに分けて赤い丸でA～Fをマッピングしています）。

なお、上図Eのクライアントとしては主にネイティブアプリケーションを想定し、そのユーザーエージェントにはWebViewを使用することを前提としています。ここではクライアントに付与されるIDトークンを用いてAPI Gatewayで認証処理を実行した後に、リソースサーバでアクセストークンの検証を行います。こちらの詳細についてはまた別途、解説します。

本連載ではほかにも複数のクライアントが登場しますが、認証／認可サーバとして「Amazon Cognito」を利用した場合、いずれもおおむね以下のような認可コードグラントフローで、クライアントがIDトークンやアクセストークンを取得するアーキテクチャにすることができます。

一度リソースオーナーからクライアントが正当に認証／認可されれば、発行されたアクセストークンを用いて、点線の枠内で継続的にマイクロサービスにアクセスするかたちとなります。アクセストークンの有効期限はデフォルトでは1時間程度に設定されているので、有効期限が切れたらリフレッシュトークンを使って、再び最新のアクセストークンを認可サーバから入手するように実装しておきます。

なお、クライアントの処理がユーザーエージェント側で実行されるものは、認可コードグラントフローでも認可コードが不当に奪取されることがないよう、コードチャレンジの値を付与するなど実装面で気を付ける必要があります(RFC7636:PKCE)。

詳細については次回以降、順次解説を進めていきますが、認証処理をはじめ、マイクロサービスからデータを取得するまでの全体的な処理の流れを理解しておくことが重要です。

*　*　*

今回は、本連載でAWS上に構成、実装していくアーキテクチャと認証／認可の全体像や考え方を解説しました。次回以降は、アプリケーションを実装するためのベースとなる環境を構築していきます。