JWT vs セッション: ステートレスかサーバー状態か?

JWTはサーバー参照なしに署名で検証される自己完結型のトークンであり、セッションは状態をサーバー側に保存しクッキーでそれを参照します。

JWT認証はclaimを署名済みトークンに入れ、サーバーがステートレスに検証するため、共有のセッションストレージなしで水平スケールできますが、即時の失効は難しくなります。セッション認証は状態をストア(メモリ、Redis、DB)に保持しセッションIDのクッキーで参照するため、容易な失効と小さなクッキーが得られますが、参照処理と共有ストレージが代償になります。JWTはステートレス性を、セッションは制御と失効を重視します。

トレードオフ

JWTは、中央のセッションストアを避けたいステートレスなAPIやサービス間呼び出しに適しています。短命に保ち、弱い失効を緩和するためrefreshトークンと組み合わせてください。セッションは、即時ログアウト、容易な無効化、小さなクッキーを必要とする古典的なWebアプリに適しており、Redisのような共有ストアを受け入れます。多くのシステムはブラウザアプリにはセッションを、APIにはJWTを使います。

CIにおいて

認証の統合テストは有効期限と失効のパスを検証すべきです。署名鍵/シークレットはCIのsecret storeに保存してください。マネージドrunnerでは、シークレットをマスクし、鍵をイメージに焼き込むことを避けてください。

結論

セッションストアを避けることが重要なステートレスなAPIやマイクロサービスには、JWT(短命でrefresh付き)です。即時ログアウトとシンプルな失効が必要なWebアプリには、サーバー側のセッションです。ハイブリッド(ブラウザにはセッション、APIにはJWT)は一般的で、各モデルの主な弱点を回避できます。

関連ガイド