JWT（JSON Web Token）は、2者間でクレームを渡すためのコンパクトな形式です。アプリケーションはログイン後にJWTを一般的に使用します。サーバーがトークンを発行し、クライアントは後続のリクエストでそれを送信し、APIはアクセスを許可する前にトークンを検証します。JWTは暗号資産トークンではなく、その内容は自動的に秘密ではありません。
金融、取引所、Web3サービスなどのアカウントシステムは、舞台裏でトークンベースの認証を使用する場合があります。デジタル資産プラットフォームを探索する読者は、Tapbitアカウントを作成できますが、開発者はすべての認証トークンをセキュリティが重要な認証情報として扱うべきです。
JWTトークンとは？
JWT標準RFC 7519は、JSONオブジェクトとして送信するために設計されたコンパクトなクレーム形式を定義しています。クレームとは、ユーザー識別子、トークン発行者、対象者、有効期限などのステートメントです。JWTは、アクセストークン、IDトークン、またはサービス間の短命メッセージとしてよく使用されます。
「JWTトークン」と言う人もいますが、最後の「T」はすでにトークンを意味します。この繰り返しは一般的で無害です。重要なのは、JWTが完全なログインシステムではなく、形式を説明していることを理解することです。安全な認証には、適切な発行、検証、保存、有効期限、失効ポリシーも必要です。
JSON Webトークンはどのように機能しますか？
一般的なログインフローは、ユーザーが有効な認証情報を送信すると開始されます。認証サーバーは、選択されたクレームを含むJWTを作成し、デジタル署名またはメッセージ認証コードで保護します。次に、クライアントはAPIにJWTを提示します。これは、Bearerスキームを使用したHTTP Authorizationヘッダー内で行われることがよくあります。
APIは署名を検証し、必要なクレームをチェックしてからリクエストを信頼します。重要なチェックには、発行者、対象者、有効期限、およびアプリケーションが期待するアルゴリズムが含まれる場合があります。検証が成功した場合、APIはクレームを使用して認可の決定を下します。失敗した場合、リクエストは拒否されるべきです。
JWTの3つの部分
一般的に見られる署名付きJWTは、ドットで区切られた3つのBase64urlエンコードされたセクションで構成されています。
header.payload.signature
- ヘッダー：トークンの種類と署名アルゴリズムを識別します。
- ペイロード：
sub（サブジェクト）、iss（発行者）、aud（対象者）、exp（有効期限）などのクレームが含まれます。 - 署名：受信者が不正な変更を検出し、正しいキーが使用された場合に署名者を検証できるようにします。
Base64urlエンコーディングは暗号化ではありません。通常の署名付きJWTを入手した人は誰でも、通常、そのヘッダーとペイロードをデコードできます。したがって、機密情報は、システムが適切な暗号化形式を使用し、明確な必要性がない限り、ペイロードに配置すべきではありません。
初心者向けJWTの例
アリスがログインした後にトークンを発行するAPIを考えてみましょう。そのペイロードは、アリスをサブジェクトとして識別し、発行者を指定し、APIを対象者として指定し、15分後に有効期限が切れる可能性があります。アリスが自分のプロファイルにアクセスしようとすると、APIはトークンを検証し、サブジェクトクレームを使用して正しいアカウントを見つけます。
誰かがペイロードをアリスの識別子から管理者への識別子に変更した場合、署名は一致しなくなります。これが署名付きJWTの主な利点です。改ざんが検出可能になります。ただし、有効な署名はすべてのクレームが適切であることを証明するものではありません。APIは、トークンが期待される発行者から発行され、そのAPIを対象としていたことを確認する必要があります。
JWT vs セッションCookie vs APIキー
| 方法 | 一般的な目的 | ステートの場所 | 主な考慮事項 |
|---|---|---|---|
| JWT | クレームとAPI認可 | トークンがクレームを運びます。サーバーはステートを保持する場合もあります | 検証と失効の設計 |
| セッションCookie | ブラウザログインセッション | 通常はサーバーサイドのセッションストア | CookieとCSRF保護 |
| APIキー | アプリケーションまたはプロジェクトの識別 | サーバーがキーと権限をマッピングします | キーはローテーションされない限り、長命の秘密です |
JWTはセッションよりも必ずしも優れているわけではありません。セッションは即時の失効を容易にすることができますが、JWTは繰り返しのデータベース検索を減らし、分散サービス全体でうまく機能します。多くのシステムは両方のアプローチを組み合わせています。たとえば、短命のJWTとサーバー管理のリフレッシュトークンレコードなどです。
JWTは暗号化されますか？
通常はされません。よく知られた3部構成のJWTは、一般的に署名されたJSON Web Signatureオブジェクトです。署名は正しく実装されていれば整合性と認証を提供しますが、ペイロードを隠すことはありません。JSON Web Encryptionは、機密性を提供できる関連標準ですが、異なる構造を使用し、キー管理の複雑さを追加します。
この区別は重要です。開発者がJWTをデコーダーに貼り付け、読み取り可能なデータが表示されて驚くことがあるためです。デコードは、署名を正常に検証することと同じではありません。アプリケーションは、デコードされたクレームのみに基づいてアクセスを許可してはなりません。
一般的なJWTセキュリティリスク
IETFのJWTベストプラクティスRFC 8725は、実際のシステムで発生した実装の失敗に対処しています。最大の問題は、基本的な形式自体からではなく、通常は不適切な検証から生じます。
- アルゴリズムの混同：予期しない、または安全でないアルゴリズムを受け入れる。
- クレームチェックの欠落：発行者、対象者、有効期限、またはその他のアプリケーション要件を無視する。
- トークンの盗難：ログ、スクリプト、安全でないストレージ、または保護されていないトランスポートを介してベアラートークンを公開する。
- 弱いキー：推測可能な秘密を使用する、または侵害された署名キーをローテーションしない。
- 長い有効期限：盗まれたトークンが長期間使用可能になるのを許す。
- 不十分な失効：署名付きトークンは早期に無効にする必要がないと想定する。
JWTベストプラクティス
アプリケーションは、サポートするアルゴリズムのみを明示的に許可し、すべての必須クレームを検証し、異なる種類のJWTに個別の検証ルールを使用する必要があります。トークンは短命であるべきで、HTTPS経由でのみ送信され、URLや通常のログからは除外されるべきです。署名キーは、安全なストレージ、ローテーション、および明確な所有権が必要です。
ストレージはアプリケーションに依存します。ブラウザシステムは、安全でHttpOnlyでSameSiteのCookieを使用する場合がありますが、モバイルまたはバックエンドクライアントは、プラットフォームに適した保護されたストレージを使用します。どのストレージ選択肢もすべての脅威を排除するわけではないため、開発者はクロスサイトスクリプティング、クロスサイトリクエストフォージェリ、トークンリプレイ、デバイスの侵害をまとめて考慮する必要があります。
結論
JWTは、検証可能なクレームをシステム間で運ぶためのコンパクトな方法です。そのヘッダーは保護方法を説明し、ペイロードはクレームを含み、署名は受信者が改ざんを検出するのに役立ちます。JWTはAPI認証を簡素化できますが、それは受信者が正しいアルゴリズム、発行者、対象者、タイミングクレーム、および署名を検証する場合に限られます。初心者にとって、重要なルールは単純です。JWTは認証設計全体が安全であることの証明ではなく、認証情報形式です。
よくある質問
JWTは何の略ですか？
JWTはJSON Web Tokenの略で、クレームをJSONとして送信するための標準化されたコンパクトな形式です。
JWTは誰でもデコードできますか？
通常の署名付きJWTを持っている人は誰でも、通常、そのヘッダーとペイロードをデコードできます。デコードは署名を検証したり、クレームを信頼できるものにしたりするものではありません。
JWTはアクセストークンと同じですか？
いいえ。アクセストークンは目的を説明し、JWTは形式を説明します。一部のアクセストークンはJWTであり、他のものは不透明な文字列です。
JWTはどのくらいの期間有効であるべきですか？
普遍的な期間はありません。アクセストークンは一般的に短命であり、正確な有効期間はシステムのリスク、失効、およびユーザビリティの要件に基づいています。
JWTは取り消すことができますか？
はい、ただし、取り消しには、デンイリスト、キーローテーション、トークンバージョニング、またはサーバー管理のリフレッシュトークンシステムなどの追加の設計が必要です。
