JWTのクレーム完全ガイド - sub/aud/exp/iat/kidを全部解説
JWTのクレームとは、トークンのPayloadに入るキーと値の組み合わせです。 JWTの中身には自由なキーを持たせられますが、RFC 7519では相互運用のためにRegistered Claims（登録済みクレーム）が標準化されています。 この記事ではJWTクレーム一覧として sub、aud、exp、iat、nbf、iss、jtiを整理し、 Headerに現れる kid まで実例付きで解説します。
JWT claims are name/value pairs carried mainly in the payload. This guide explains the registered claims iss, sub, aud, exp,nbf, iat, and jti, plus the header parametersalg, typ, and kid, public and private claims, decoding, and the risk of placing personal data in a readable token.
図1: HeaderとPayloadに入る代表的な項目
kidは正確にはJWT Headerのパラメーター
JWT標準クレーム（Registered Claims）一覧
Registered Claimsは利用必須ではありません。用途に必要なものを採用し、検証側で期待値を確認します。
| クレーム | 意味 | 典型的な値・用途 |
|---|---|---|
iss | Issuer（発行者） | 認証サーバーのURLなど。信頼する発行元か検証 |
sub | Subject（主体） | ユーザーIDなど、トークンが表す主体の識別子 |
aud | Audience（想定利用者） | 受け取り先のAPI識別子。文字列または文字列配列 |
exp | Expiration Time（失効時刻） | この時刻以降は受理しないUnix秒 |
nbf | Not Before（有効化前時刻） | この時刻より前は受理しないUnix秒 |
iat | Issued At（発行時刻） | 発行されたUnix秒。経過時間の判断に使う |
jti | JWT ID | 固有ID。使用済みIDを記録してリプレイ攻撃を防ぐ |
exp、iat、nbfの詳細は、JWTの有効期限切れを確認する方法で解説しています。
sub・aud・issは「誰が、誰について、誰向けに」発行したか
JWTのsubとはトークンが表す主体で、多くは変更されにくい内部ユーザーIDです。issは発行した認証基盤、audは利用を許可されたAPIを示します。 APIは署名だけでなく、想定する iss と aud への一致も検証します。
{"iss":"https://auth.example.com/","sub":"user_7f3a92","aud":["https://api.example.com","account-api"]}exp・nbf・iatとjtiの役割
expは利用期限、nbfは利用開始時刻、iatは発行時刻です。 JWTのiatだけでは失効時刻を表さないため、期限判定には exp を使います。jtiは一意なJWT IDで、使用済みIDや拒否対象IDを記録すればリプレイ攻撃を検出できます。
図2: 標準クレームを確認する順序
Headerのalg・typ・kidはPayloadクレームではない
JWTのkidとは Key ID（鍵ID）のことで、複数の公開鍵から 署名検証に使う鍵を選ぶためのHeaderパラメーターです。鍵ローテーション時には新旧鍵を並行公開し、kidで該当鍵を特定します。algは署名アルゴリズム、typは通常 JWT を表します。
| Header | 役割 |
|---|---|
alg | RS256、HS256など署名に使うアルゴリズム |
typ | トークンの種類。通常はJWT |
kid | 検証鍵を選ぶ識別子。鍵ローテーションで利用 |
詳細はJWT HS256とRS256の違いとJWT署名検証が失敗する原因も参照してください。
Public ClaimsとPrivate Claimsの違い
Public ClaimsはIANA登録などで名前の衝突を避けて共有するクレームです。Private Claimsは発行者と利用者が合意するアプリ独自のクレームです。subにユーザーIDを置き、roleやpermissionsを足すケースがあります。 独自名の衝突や値の陳腐化に注意し、重要な認可判断ではサーバー側の最新状態も考慮します。
{"sub":"user_7f3a92","role":"editor","permissions":["articles:read","articles:write"]}JWTの中身をデコードしてクレームを確認する
JWTの中身確認には当サイトのJWT Decoderを使えます。 最初のHeader欄に alg、typ、kid、次のPayload欄にsub、aud、expなどが表示されます。
Header
{"alg":"RS256","typ":"JWT","kid":"key-2026-07"}
Payload
{"iss":"https://auth.example.com/","sub":"user_7f3a92","aud":"https://api.example.com","exp":1784649600,"nbf":1784646000,"iat":1784646000,"jti":"01JZ8M4N5P6Q7R8S9T"}デコードは署名検証ではありません。信頼する前に、サーバー側で署名と各クレームを検証してください。
よくある間違い: subに個人情報を平文で入れる
subにメールアドレス、氏名、電話番号などを入れるのは避けましょう。 通常のJWT（JWS）は署名されるだけで暗号化されません。秘密鍵がなくても誰でも HeaderとPayloadを読めます。subには推測しにくい内部IDを使い、Payloadに機密情報を入れない設計が安全です。
注意: デコードできることと信頼できることは別
JWTのPayloadは誰でも読め、改ざんした文字列も作れます。認証・認可では署名とクレームを検証してください。
English summary
RFC 7519 defines registered claims: iss identifies the issuer,sub the subject, aud the audience, exp/nbf/iatthe relevant times, and jti a unique token ID. alg, typ, andkid belong to the header; kid selects a verification key during rotation. Public claims use shared collision-resistant names, while private claims such as role andpermissions are application-specific. JWTs are signed, not encrypted, so never put email addresses or sensitive personal data in sub. Decode for inspection, but verify before trusting.