UD Day 17 アーキテクチャーの検討12(Authを考慮したアプリサーバー構成)

仮に認証方式としてJWTを採用する場合のアプリサーバーの構成がどのようになるか?について、考察してみたいと思います。

JWTには、有効期限の短いaccess tokenと有効期限の長いrefresh tokenの2つを用いるというやり方があります。
クライアントは、初回ログインで認証を行うサーバーから上記二つを得て、以降のやり取りでは、必ずaccess tokenをつけて、トランザクション処理を行います。
access tokenが期限切れとなったら、refresh tokenを使って、認証サーバーからaccess tokenを発行してもらい、以降のやり取りではこれをつけて、トランザクション処理を行います。refresh tokenと有効期限の情報は、DBに保存します。Refresh tokenがJWTの形式の場合、exp(有効期限)をtokenの2つ目のClaim内に含むので、tokenのみを保存すれば良いということになります。
実際のログイン時のHandshake(クライアント・サーバー間の処理の流れ)は別記事にて記載予定ですが、上記を踏まえると、サーバーの機能としては認証を行うものとそれ以外の処理を行うものの2つに分けることができそうです。つまり、以下のような構成になります。

サーバー構成と利用するTokenの種類

上記の構成でAuth ServerとResource Serverがそれぞれ認証サーバー、それ以外の処理用のサーバーとなりますが、これらの役割を共有にするという考え方もできます。しかしながら、トークンの生成・解読の際に利用する秘密鍵の漏洩に対するリスクを最小化する場合には、共有よりも役割を分けることが望ましいと考えました。その結果として、上記の構成を採用しています。(続く)

参考リンク)
JWTの実装方法についての質問

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です