【テクニカル・上級編】 JWTの署名アルゴリズム(RS256 vs HS256)の選択基準 – Web APIアーキテクチャ・データ連携実践ガイド

JWTの署名アルゴリズム、RS256 vs HS256：インフラアーキテクトが「あえて」選ぶべき現実解

ネットワークの深淵を覗く諸君、今日もパケットの海を泳いでいることだろう。

Web APIの認証においてJWT（JSON Web Token）はもはや空気のような存在だ。しかし、その「署名アルゴリズム」の選択ひとつで、システム全体のセキュリティ境界とスループットが劇的に変わることを、どれほどのエンジニアが意識しているだろうか。

今回は、HS256（HMAC with SHA-256）とRS256（RSA Signature with SHA-256）の比較を、教科書的な「セキュリティ比較」という低レイヤーの議論から一段引き上げ、インフラアーキテクトの視点でパケットレベルの挙動まで掘り下げる。

HS256：共有鍵の呪縛と「信頼の限界」

HS256は対称鍵暗号だ。サーバーとAPIゲートウェイが同じ秘密鍵を共有する。

この方式の最大のメリットは「計算コストの低さ」にある。CPUのパイプラインを浪費せず、HMACの計算は極めて高速だ。しかし、ネットワークトポロジーが複雑化する現代において、これは脆弱性の温床となる。

なぜ「共有鍵」はスケールしないのか

マイクロサービスアーキテクチャにおいて、認証サーバーと検証を行うAPIゲートウェイ（あるいはサイドカープロキシ）が分離している場合、すべてのノードに同じ秘密鍵を配布しなければならない。

鍵漏洩リスクの拡散: 1箇所でもコンテナのメモリダンプや設定ファイルが漏洩すれば、システム全体が崩壊する。
鍵更新の地獄: 鍵をローテートする際、ネットワーク内の全ノードでアトミックに更新するのは不可能に近い。伝搬遅延の間、サービスは不整合に陥る。

RS256：非対称鍵がもたらす「分離の美学」

一方で、RS256は公開鍵暗号を用いる。認証サーバー（秘密鍵）とAPIゲートウェイ（公開鍵）で役割を明確に分断できる。

インフラアーキテクトがRS256を推す理由

APIゲートウェイの役割は、バックエンドのサービスを守る盾だ。RS256であれば、ゲートウェイは公開鍵さえ持っていればよい。万が一ゲートウェイが侵害されても、トークンの偽造（署名生成）は不可能だ。この「権限の分離」は、ゼロトラストアーキテクチャの基本要件である。

パケットレベルでの最適化：署名検証のコストをどう殺すか

「RS256は検証負荷が高い」という懸念は、確かに存在する。RSA署名の検証は、HMACに比べて計算量が大きい。しかし、ネットワーク全体のRTTやTLSハンドシェイクのオーバーヘッドに比べれば、微々たるものだ。

さらに、以下の手法でパフォーマンス劣化をゼロに近付けることができる。

1. 公開鍵のキャッシュとJWKSの活用

APIゲートウェイで毎回 /.well-known/jwks.json をフェッチするのは愚の骨頂だ。ゲートウェイのメモリ上に公開鍵をLRUキャッシュし、Cache-Control ヘッダーに従って適切に更新する仕組みを構築せよ。

2. TLSハンドシェイクの最適化

JWT検証以前に、TCP/TLSのオーバーヘッドを削減する。TLS 1.3 の 0-RTT 接続や、OCSP Stapling を有効にすることで、ハンドシェイクのRTTを削り取り、署名検証に計算リソースを回す余裕を生み出す。

# NginxでTLS 1.3とOCSP Staplingを有効化し、RTTを最小化する設定
ssl_protocols TLSv1.3;
ssl_stapling on;
ssl_stapling_verify on;
# HTTP/2を有効にし、ヘッダー圧縮(HPACK)でトークン伝送の負荷を軽減
http2 on;

実践：JWT検証のベストプラクティス

Pythonで実装する場合、PyJWT などを用いて以下のように公開鍵を扱うのが定石だ。

import jwt
from cryptography.hazmat.primitives import serialization

# 認証サーバーから取得した公開鍵を読み込む
# 本来はJWKSエンドポイントから取得し、キャッシュしたものを使用すること
public_key = """-----BEGIN PUBLIC KEY-----
... (公開鍵データ) ...
-----END PUBLIC KEY-----"""

def verify_token(token):
    try:
        # RS256を指定。アルゴリズムを明示的に固定し、
        # "alg": "none" 等の脆弱性攻撃をブロックする
        payload = jwt.decode(
            token, 
            public_key, 
            algorithms=["RS256"]
        )
        return payload
    except jwt.InvalidTokenError as e:
        # ログには詳細を出すが、クライアントには詳細を返さない(セキュリティ要件)
        log_error(f"Token verification failed: {e}")
        return None

結論：ネットワークを「信頼」するな

HS256は、単一のモノリスアプリケーションで、かつ鍵管理が完全に制御できる環境でのみ許される贅沢だ。しかし、現代の分散システムにおいては、RS256を採用しない理由がない。

署名検証の計算負荷を恐れるあまりセキュリティを犠牲にするのは、インフラアーキテクトとして本末転倒だ。CPUのクロックサイクルを削ってでも、署名の検証にはRSAやECDSA（ES256）のような非対称鍵方式を選び、ネットワークの信頼境界を強固に保つこと。

パケットが暗号化され、ゲートウェイがそれを正しく検証し、バックエンドへ流れる。この一連のフローこそが、我々インフラエンジニアの矜持だ。

諸君、アルゴリズムの選択ひとつで、ネットワークの品格を変えていこうではないか。