JWTをデコードを整える。

—

—

そもそも JWT とは

「この人はログイン済みです」を、書き換えられない形で持ち歩く通行証。

どこで・どんな場面で使うか

• Web サービスのログイン後の API 呼び出し

  ログインで受け取った JWT を、リクエストのたびに Authorization ヘッダに付けて送り、「ログイン済み」を証明します。

• スマホアプリとサーバーのやりとり

  アプリはトークンを保持し、期限が切れたら再取得します。サーバー側に状態を持たなくてよい、という利点もあります。

• シングルサインオン（SSO）やソーシャルログイン

  OpenID Connect の ID トークンは JWT 形式です。「Google でログイン」の裏側にも出てきます。

• マイクロサービス間の通信

  複数のサーバーが連携するとき、「誰の依頼か」を JWT で次々に引き継ぎます。

• ログイン不具合の調査

  「期限切れ」「対象が違う」などの原因は JWT の中身に書かれています。貼って読めば切り分けが早く進みます。

知らないと何が困るか

• 「暗号化されているから安全」と思い込む。中身は誰でも読めます。個人情報や秘密を JWT の中に入れると、そのまま見えてしまいます。
• トークンを人に見せてしまう。JWT は持っている人が本人として扱われる通行証です。チャットや画面共有で貼り付けると、悪用される恐れがあります。
• 認証エラーの原因探しが長引く。有効期限（exp）の切れや発行元の違いを読み取れないと、「ログインできない」の理由が分かりません。

上のツールにトークンを貼ると、中身が読めることを確かめられます。この確認の安全な練習には、付属のサンプルを使ってください。

JWT の仕組み・4つ

「読める」けれど「書き換えられない」── 署名が守るのは中身ではなく改ざん。

1. 1

   3つの部分を「.」でつなぐ

   JWT は header（型・署名方式）.payload（中身）.signature（署名） の3部構成。それぞれ Base64URL でエンコードされているだけで、暗号化はされていません。だから誰でも中身を読めます。

2. 2

   payload に「主張（クレーム）」が並ぶ

   誰のトークンか（sub）、誰が発行したか（iss）、いつまで有効か（exp）などが入ります。サーバはこれを読んで「このユーザーは誰で、何が許されているか」を判断します。

3. 3

   署名は「改ざん検知」のためのもの

   payload を書き換えると署名が合わなくなり、サーバが弾きます。署名は中身を隠すためではなく、勝手な書き換えを防ぐため。検証には鍵が要るので、このツール（鍵なしデコード）では行いません。

4. 4

   時刻は Unix 秒（NumericDate）

   iat / nbf / exp は「1970年1月1日からの秒数」で入ります。人間には読みづらいので、このツールが 日本時間（JST）と UTC に変換し、exp が現在より前なら「期限切れ」と判定します。

🔒 デコードはすべてあなたのブラウザの中（純 JavaScript・Base64URL → UTF-8 → JSON）で完結します。貼り付けたトークンはサーバに送られません（送信ゼロ）。署名の検証は行いません（鍵が要るデコードのみ）。