結論
kong で jwt plugin 入れると、kong を経由して呼ばれる api は jwt の検証ロジックを持たなくて済むので安心して到達した jwt を使えるということ。
signature 検証を kong 側でやってくれるため。
検証も kong がキャッシュを使いながらうまいことやってくれるのでこのあたりのスケールに対する問題を考えなくて済む。
仕組み
jwt plugin を入れると kong 側で consumer というアプリケーションでの認証対象を管理できるようになる。
consumer には jwt 発行時の署名に使う secret が多で紐づくようになっていて、対象の consumer に対して jwt を発行するときには都度生成できるようになっている。
consumer 毎に署名に使う情報が異なるため、秘密鍵が漏れてしまっても影響は局所的。
kong 側が jwt の署名に使う情報を持っているため、ユーザが認証を必要としている api をコールしたときに、そのときに受信した jwt の検証を行える。
試しに jwt の改ざんを行ってみたが、kong から 403 が返された。
認証後に受け取った jwt の header.payload.signature のうち、payload 部分を一部書き換えて api コールを行ってみた結果である。
jwt.io を使って、payload の一部を書き換えた。
なぜ 403 になるかというと、 consumer 認証時に発行した signature が kong 側で header.payload を consumer の secret で hash 化したものが等しくないからである。
jwt を発行するのは、kong ではなく api がやることなので、以下のようなやりとりは sign in(ログイン) 時やユーザ登録時に必要。
- ユーザ作成時、api から kong に consumer 作成をする
-
ユーザ認証時、api から kong に jwt に必要な署名情報作成をさせる
- レスポンスに含まれる署名情報を使って、api 側で jwt を組み立てて user に返す
その他
kong で署名情報を持つことで、jwt の無効化も kong の持つ署名情報を消すことで可能になっている。地味に便利。