マイクロサービスで JWT が使われる理由

中級 | 9分 で読める | 2026.06.14

公式ドキュメント
マイクロサービスJWT認証API

マイクロサービスと認証

マイクロサービスでは、1つの大きなアプリを機能ごとの小さなサービスに分けます。

たとえば、ECサイトなら次のように分かれます。

  • ユーザーサービス
  • 注文サービス
  • 決済サービス
  • 在庫サービス
  • 通知サービス

これらのサービスはAPIで通信します。そこで問題になるのが、サービス間で「誰のリクエストか」「どの権限か」をどう伝えるかです。

従来のセッションの課題

従来のサーバ側セッションでは、ログイン状態はRedisやDBなどのセッションストアにあります。

session_id -> session store -> user情報

マイクロサービスで全サービスが毎回セッションストアを見ると、次の課題が出ます。

課題内容
共有ストア依存全サービスが同じセッションストアに依存する
レイテンシ毎回ストア問い合わせが発生する
結合度認証基盤との結合が強くなる
障害影響セッションストア障害の影響が大きい

JWT の便利さ

JWTを使うと、各サービスは署名を検証してユーザー情報や権限を確認できます。

Request with JWT
-> Service A verifies signature
-> Service B verifies signature
-> Service C verifies signature

中央のセッションストアに毎回問い合わせなくても、トークンの署名、有効期限、audience、scopeなどを見て判断できます。

{
  "sub": "user_001",
  "scope": "orders:read",
  "aud": "order-api",
  "exp": 1760000000
}

サービス間では JWT が有効

JWTは、サーバ間・サービス間の認証では便利です。

利点内容
分散検証各サービスが署名検証できる
スケールしやすいセッションストア参照を減らせる
権限を含められるscopeやaudienceを表現できる
標準化されているOAuth/OIDCと相性がよい

ただし、JWTに何でも入れてよいわけではありません。Payloadは読まれる前提で、機密情報は入れません。

ブラウザに持たせる話とは別

ここが重要です。

マイクロサービスでJWTが便利だからといって、ブラウザにJWTを持たせる必要があるとは限りません。

現在の構成では、次のように分けることができます。

Browser -> Cookie -> BFF -> JWT -> Microservices

ブラウザはBFFにCookieでアクセスします。BFFがサーバ側でJWTを使い、マイクロサービス群を呼びます。

ポイント: JWT はサーバ間では便利です。しかし、その利点はブラウザにJWTを置く理由にはなりません。

JWT の注意点

マイクロサービスでJWTを使う場合も、注意点があります。

  • 有効期限を短くする
  • aud を検証する
  • iss を検証する
  • 署名アルゴリズムを固定する
  • 鍵ローテーションを考える
  • 失効要件を整理する
  • 権限情報を大きくしすぎない

特に aud の検証は重要です。別API向けに発行されたJWTが誤って使われないようにします。

Service Mesh や mTLS との関係

マイクロサービス間の認証では、JWTだけでなく mTLS や Service Mesh も使われます。

方式主な役割
JWTユーザーや権限を伝える
mTLSサービス同士の本人確認と暗号化
Service Mesh通信制御、認証、監視を共通化

JWTは「誰の代理か」を伝え、mTLSは「どのサービスから来たか」を確認する、というように役割を分けることがあります。

まとめ

マイクロサービスでJWTが使われる理由は、各サービスが署名検証だけで認証情報を確認しやすいからです。

  • セッションストア依存を減らせる
  • 各サービスで分散検証できる
  • scopeやaudienceをトークンに含められる
  • OAuth/OIDCと相性がよい
  • ただし即時失効や鍵管理には注意が必要
  • サーバ間でJWTが便利なことと、ブラウザにJWTを持たせることは別問題

参考リソース

次に読む記事

おすすめ記事

← 一覧に戻る
PR
PR
PR
PR