NGINX Plusで OAuth2.0 のアクセストークンを検証をする その1

はじめに

スマートフォンアプリや Web サービス、業務アプリケーションなど、私たちが日常的に使うアプリは単独で動いているわけではなく、他のサービスと連携することが当たり前になってきています。
たとえば、ToDo アプリから google カレンダーの予定を参照/追加したり、家計簿アプリが銀行口座と接続して明細を自動的に取得したりと様々な場面でアプリ同士が連携しています。
本ブログでは、アプリケーション間の連携に欠かせない、OAuth2.0 の概要とアクセストークンの検証について紹介していきます。

なお、本ブログは以下のような2部構成となっております。

• OAuth2.0 アクセストークンについて
• NGINX Plus でアクセストークンを検証する設定方法

第1弾である今回は、OAuth2.0 の概要とアクセストークンの検証について解説いたします。

アプリケーション間の連携方法

さて、アプリケーションの連携を実現するためには、アプリケーションが保持するユーザー情報を別のアプリが利用できるようにしなければいけません。
例えば、ToDo アプリが Google カレンダーの予定を読み書きするためには、ToDo アプリから Google にアクセスできるようにしなければいけません。

では、ToDo アプリに Google のアカウント情報を渡せばよいのでしょうか？
確かに Google カレンダーにはアクセスできるようになりますが、Todo アプリは Google カレンダー以外のサービス(Gmail や Google photo)にもアクセスできてしまいますし、Todo アプリから Google のアカウント情報が漏洩するリスクもあります。
そのため、ToDo アプリには「利用者が持つ Google アカウントからカレンダー」にのみにアクセスできるようにする必要があります。

これを実現するために広く使われているのが「OAuth2.0」という認可の仕組みです。
OAuth2.0 を利用することで、ToDo アプリは Google カレンダーに対してのみ読み書きができるようになります。

OAuth2.0 について

OAuth 2.0 は、ユーザーの許可をもとに、外部アプリが必要なデータにアクセスできるようにするための“認可”の仕組みです。
そのため、ユーザーが「Todo アプリによる Google カレンダー情報へのアクセス」を許可した場合、アプリは Google カレンダーの情報だけを取得/更新することができるようになります。
また、OAuth2.0 では、ユーザーパスワードをやり取りしないため、安全に連携することが可能です。

そして、これらの連携の中核となるのが「アクセストークン」と呼ばれるものです。

アクセストークンについて

アクセストークンとは、ユーザーの許可を受けて発行されるものであり、Todo アプリがこのトークンを含めて Google にリクエストを送ることで、Google カレンダーへのアクセスが可能となります。
そして、このアクセストークンには有効期限や利用可能な範囲などが含まれており、この内容の範囲内でデータの取得や操作が許可されます。

では、アクセストークンはどのように発行されるのかを見てみましょう
※ 以下の図は、イメージの理解を優先したものであり、実際のフローから省略している部分があります。

各コンポーネントとしては以下の通りです。
ユーザー : google カレンダーと Todo アプリの利用者
認可サーバー: ユーザーデータの管理サーバー (google 認可サーバー)
クライアントアプリ : 別のアプリの情報を取得したいアプリ (ToDo アプリ)
リソースサーバー : API を公開しているサービス(Google Calendar API )

この図のように、クライアントアプリは認可サーバーに対して、アクセストークンの発行を依頼すると、認可サーバーがユーザーに確認を行い問題なければ、アクセストークンが発行されます。
その後、クライアントアプリはアクセストークンを含めてリソースサーバーにリクエストを送ります。

アクセストークンの検証について

今度は、クライアントアプリとリソースサーバー間でアクセストークンがどのようにやり取りされるか(先の図の④の部分)を見てみましょう。

クライアントアプリは、リソースサーバーに対してアクセストークンを含めてリクエストを送ります。
そして、アクセストークンを受け取ったリソースサーバーでは、アクセストークンの内容とリクエスト内容を確認して許可するかを判断します。
また、アクセストークンの検証方法はトークンの形式によって二つのパターンがあります。
具体的にはアクセストークン自体にユーザー情報が含まれているパターンと、認可サーバーに問い合わせることでユーザー情報を取得するパターンの二つです。

次は、そんなアクセストークンの形式についてみていきましょう。

アクセストークンの形式について

先に説明した通り、アクセストークンの形式については大きく2種類あります。
それぞれ簡単に説明すると

アクセストークン自体にユーザー情報が含まれているパターン

アクセストークン内にユーザー情報や有効期限の情報が含まれており、JWT が使用されています。
JWT を使用することで、アクセストークン内のユーザー情報や有効期限が改ざんされていないかを確認することができます。
詳しくは こちら であつふみさんが解説しています。

認可サーバーに問い合わせることでユーザー情報を取得するパターン

アクセストークン自体は意味を持たない単純な文字列であり、この文字列をキーとして認可サーバーに問い合わせを行うことで、アクセストークンの有効性とユーザー情報を取得する方法となります。

API Gateway の導入

さて、ここまでに説明した通り、OAuth2.0 を利用するためには、「アクセストークンの検証」が必要となるわけですが、この検証をどこで実施するのがよいでしょうか？

図にある通り、リソースサーバーでしょうか？
もちろん、リソースサーバーで実装されているケースもありますが、以下のような課題もあります。

• リソースサーバー毎にアクセストークンに対応するために、異なる言語やロジックで開発を必要がある
• 不正なトークンがリソースサーバーに到達してしまう
• Opaque 形式の場合、認可サーバーへの問い合わせが集中することによりパフォーマンスが低下してしまう

こうした課題を解決する手段として、リソースサーバーの前段に NGINX Plus を配置して、 API Gateway として活用する方法がございます。
NGINX Plus を API Gateway として活用すると、アクセストークンの検証をオフロードできるため、アプリケーション開発の負荷を低減できるだけでなく、不正なトークンを拒否したり、認可サーバーへの問い合わせ結果をキャッシュすることが可能となります。

そのほかにも、NGINX Plus は以下のような機能を持っており、これらの機能を活用することでアプリケーションの負荷を軽減しつつ、API のセキュリティレベルを高めることができるようになります。

• 軽量・高速な処理
• JWE や Nested JWT の復号
• 検証結果や JWK Set のキャッシュ
• API リクエストのレート制御

NGINX Plus でアクセストークンをどうやって処理するのかや、その設定方法などは次回のブログで紹介します。

まとめ

今回は アプリ間連携で使用される OAuth2.0 の概要と、アクセストークンの検証における課題とその解決策について記載いたしました。

第2弾では実際に NGINX Plus でアクセストークンを検証する方法と具体的な設定例を記載していきたいと思います。
NGINX Plus を使うと、OAuth2.0 との連携が簡単に構成できるようになるだけでなく、セキュリティ面も強化することができるようになりますので、第2弾のブログも読んでいただけると幸いです。

ここまで読んでいただきありがとうございました。