JWT クレームとは？解説

JWT クレームはトークンのペイロードに含まれる単一の主張で、たとえば誰が発行したか、それが誰についてか、いつ期限切れになるかなどです。

JWT は実際には署名されたクレームの袋にすぎず、意味が宿るのはクレームの中です。各クレームはトークンの subject に関するキーと値の主張です。標準クレームはアイデンティティと有効性を記述し、カスタムクレームはアプリケーションが必要とするものを何でも運びます。CI では、OIDC トークン内のクレームこそが、クラウドプロバイダがアクセスを許可するかを判断するために調べるものです。

JWT クレームとは何か

クレームは JWT の JSON ペイロード内の 1 つのエントリで、トークンまたはその subject について何かを主張するキーとその値です。issuer によって署名されたクレームの集合が、検証者が認可の判断を下すために読むものです。JWT は署名されているだけで暗号化されていないため、クレームは誰でも読めます。

登録済み（標準）クレーム

いくつかのクレームは標準化されています。issuer（トークンを発行した者）、subject（それが識別する者）、audience（誰のためか）、有効期限、発行時刻です。検証者は、トークンが期限切れでないこと、そして audience が自分に一致することを、信頼する前に日常的にチェックします。

カスタムクレーム

標準セットに加えて、issuer はアプリケーション固有のクレームを追加できます。たとえば CI の OIDC トークンは、リポジトリ、branch または tag、workflow、環境を記述するクレームを運びます。これらにより、リライングパーティはアカウント全体ではなく、非常に特定のパイプラインに信頼をスコープできます。

CI における JWT クレーム

workflow が OIDC トークンを要求すると、クラウドプロバイダはそのクレームを信頼ポリシーと照合します。subject クレームがあなたの repo と branch に一致するトークンだけが role を引き受けることを許されます。その subject クレームの条件を正しく設定することが、CI からの安全で鍵なしのクラウドアクセスの核心です。

Scoping access by a JWT claim

# A trust policy condition on the OIDC subject claim
# "sub": "repo:acme/app:ref:refs/heads/main"
# AWS condition (conceptual):
#   StringEquals:
#     token.actions.githubusercontent.com:sub: repo:acme/app:ref:refs/heads/main

Latchkey に関する注記

Latchkey runner で workflow が取得する OIDC トークンは、同じ標準の repo、branch、環境のクレームを運ぶため、subject クレームでマッチするあなたのクラウド信頼ポリシーは変更なしに機能し続けます。

重要なポイント

JWT クレームは、トークンまたはその subject に関するペイロード内の単一のキーと値の主張です。
標準クレームは issuer、subject、audience、有効期限をカバーし、カスタムクレームはアプリケーションのデータを運びます。
CI の OIDC トークンは repo と branch のクレームを運び、クラウドの信頼ポリシーはそれらをマッチさせてアクセスをスコープします。