OAuth vs JWT: プロトコルかトークン形式か?
OAuth 2.0は委任アクセスのための認可フレームワークであり、JWTはトークン形式です。両者は異なる問題を解決し、しばしば一緒に使われます。
OAuth 2.0は、アプリがユーザーのパスワードを扱わずにリソースへの委任アクセスを取得するフローを定義し、accessトークンとrefreshトークンを発行します。JWTはコンパクトで署名されたトークン形式で、claimを運び、データベース参照なしで検証できます。OAuthはしばしばJWTをaccessトークンとして発行しますが、OAuthなしでJWTを使うことも、不透明なトークンでOAuthを使うこともできます。両者は競合ではなく補完関係にあります。
| OAuth 2.0 | JWT | |
|---|---|---|
| 正体 | 認可フレームワーク | トークン形式 |
| 範囲 | 委任アクセスのフロー | claimをエンコード |
| 検証 | トークンの種類に依存 | 署名(ステートレス) |
| 併用 | トークンを発行 | そのトークンになり得る |
| 最適な用途 | サードパーティアクセス | ステートレスなclaim |
両者の関係
委任認可が必要なとき、つまりユーザーがアプリに別のサービス上の自分のデータへのアクセスを許可できるようにするとき(「Xでサインイン」やAPIアクセスのフロー)はOAuthを使います。アイデンティティやclaimを運ぶ自己完結型で検証可能なトークンが必要なときはJWTを使います。OAuthプロバイダは一般にJWTのaccessトークンを返すため、正しい捉え方は「どのOAuthフロー」に加えて「どのトークン形式」です。
CIにおいて
パイプラインはしばしばOAuthのクライアント認証情報を短命のトークンと交換してAPIを呼び出します。シークレットはCIのsecret storeに保存し、コードには決して入れないでください。マネージドrunnerでは、トークンの出力をマスクし、長命のシークレットを避けるため可能な限りOIDCを使ってください。
結論
委任アクセスと標準的なログイン/認可フローが必要なら、OAuth 2.0です。claimを運ぶステートレスで検証可能なトークンが必要なら、JWTです。一般的で正しい構成は、JWTのaccessトークンを発行するOAuthフローです。両者は同じシステムのレイヤーであり、二者択一ではありません。