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

中級 | 8分 で読める | 2026.06.14

公式ドキュメント
JWTAuthAPI

マイクロサービスと認証

マイクロサービスでは、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、token種別などを確認できます。

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

サービス間では JWT が有効

BFFがOrder API向けJWTを同じresource audience配下の2 instanceへ送り、各instanceが署名、issuer、audience、期限、scopeと権限を段階的に検証する図

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

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

ただし、JWTに何でも入れてよいわけではありません。Payloadは読まれる前提で、機密情報は入れません。また、有効なJWTでも、その利用者が対象の注文などを操作できるかは各サービスが認可します。

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

ここが重要です。

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

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

Browser -> Cookie -> BFF -> access token -> Microservices

ブラウザはBFFにCookieでアクセスします。BFFがサーバー側でaccess tokenを使い、マイクロサービス群を呼びます。access tokenはJWT形式とは限りません。

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

JWT の注意点

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

  • 有効期限を短くする
  • 検証側で署名アルゴリズムを許可リストにする
  • iss、aud、exp、必要ならnbfとtoken種別を検証する
  • scopeに加えて、対象リソースへの業務認可を行う
  • 公開鍵の配布、キャッシュ、鍵ローテーションを設計する
  • 失効反映までの時間とreplay時の影響を整理する
  • 権限情報を大きくしすぎず、変更反映の遅れを考慮する

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

Service Mesh や mTLS との関係

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

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

JWTは「どの主体・権限を伝えるか」、mTLSは「どのサービスとの通信か」を確認する、というように役割を分けることがあります。片方があればもう片方の検証や業務認可が不要になるわけではありません。

まとめ

マイクロサービスで自己完結型JWTが使われる理由は、各サービスが認証サーバーへ毎回問い合わせずに検証できる構成を作れるからです。

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

参考リソース

次に読む記事

おすすめ記事

← 一覧に戻る
PR
PR
PR
PR