JWT のデコードと検証: 開発者が確認すべき違い

JWT はデコーダーに貼り付けるだけで header と payload を読めるため、デバッグでは便利です。危険なのは、読めた JSON をそのまま信頼できる証拠として扱うことです。

デコードが答える質問は「この token は何を主張しているか」です。検証が答える質問は「信頼できる発行者が、この audience とルールに対して、この token に署名したか」です。

デコードで分かること

JWT の header と payload は Base64URL で表されているため、署名鍵がなくても読めます。デコーダーでは次のような情報を確認できます。

• alg や typ
• sub
• iss
• aud
• exp
• iat
• nbf
• custom claim

これらは調査の手がかりになります。たとえば exp が過去になっている、aud が期待と違う、sub が想定ユーザーではない、といった問題を見つけられます。

検証で確認すること

検証では、少なくとも署名、発行者、有効期限、audience、使用できるアルゴリズムを確認します。アプリケーションによっては、tenant、scope、role、nonce なども見る必要があります。

重要なのは、payload の中身だけで認可判断をしないことです。攻撃者は署名を知らなくても、見た目だけそれらしい header と payload を作れます。

デバッグ時の安全な考え方

JWT Decoder は「何が入っているか」を見るために使います。アプリケーションやバックエンドの検証ロジックは「それを信頼してよいか」を判断します。

この 2 つを分けておくと、ログ調査、OAuth 設定ミス、期限切れ token、audience mismatch を安全に切り分けられます。