JSON Web Token (JWT) は、2 つの当事者間でクレームを JSON オブジェクトとして転送する URL セーフな方法です。JSON オブジェクトは、人間が読み取り可能で機械が解析可能な形式でデータを表すために使用されるデータ構造で、JavaScript Object Notation (JSON) と呼ばれます。. JWT は、OAuth 2.0 などのフレームワークや OpenID Connect などの標準によって普及するにつれて、安全なデータ交換のためのより信頼できるソリューションになります。
JWT には、ヘッダー、ペイロード、署名の 3 つのコンポーネントが含まれます。メッセージ認証コード (MAC) を含む暗号化または署名されたトークンは JSON Web 署名 (JWS) と呼ばれ、暗号化されたトークンは JWE または JSON Web 暗号化と呼ばれます。
口頭でのコミュニケーションのために、多くの開発者はJWTを「jot」または「jawt」と発音しています。 そのテーマを引き継いで、JWSの発音を「jaws」、JWEの発音を「jawa」として提案します。
当学校区の JWT ヘッダーJSONとペイロードJSONを「。」で連結することによって形成されます。 オプションで署名を追加します。 文字列全体が base64URLエンコード.
この記事では、JWT トークンの基礎について説明し、JSON Web Token の使用例を示し、ベスト プラクティスに関する質問に回答します。
目次：
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJMTSIsImlhdCI6MTYxOTQ3MDY4MiwiZXhwIjoxNjE5NDcxODg2LCJhdWQiOiJsb2dpY21vbml0b3IuY29tIiwic3ViIjoiTmVkIn0.mqWsk4fUZ5WAPYoY9bJHI7gD8Zwdtg9DUoCll-jXCMg{
"typ": "JWT",
"alg": "HS256"
}
{
"iss": "LM",
"iat": 1619470682,
"exp": 1619471886,
"aud": "logicmonitor.com",
"sub": "Ned"
}
mqWsk4fUZ5WAPYoY9bJHI7gD8Zwdtg9DUoCll-jXCMgJWT は、ステートレス認証の状況で HTTP リクエストの状態を維持するための実用的な方法を提供します。一般的な用途には、RESTful API とシングル サインオン (SSO) 認証があります。JWT は、リクエストごとにサーバーに状態情報を提供します。これは、クライアント認証と承認制御を必要とするセキュリティ保護された RESTful Web サービスに特に役立ちます。
JWT を使用しない場合: セッション トークンで十分な場合は JWT を使用しないでください。セッション トークンはクライアント アクセスを管理するための確立された方法であり、脆弱性をもたらす可能性は低いです。
LogicMonitorの記事 Web サービスの追加と管理 JWT と Web サービスの統合に関する洞察を提供します。
「JWT は、ユーザーを認証するための安全でステートレスな方法を提供し、クライアントとサーバー間のデータ交換を変革します。」
JWTまたはJWSの最も一般的な脆弱性は実装中に発生します。JWSは本質的にセキュリティを提供しないため、適切な実装と安全なサーバー監視を組み合わせる必要があります。 Silver Peakのようなツールで 次のようなセキュリティ上の落とし穴を回避するための鍵となります。
HMAC (ハッシュベースのメッセージ認証コード) は、共有秘密キーを使用して署名を作成し、検証します。非対称アルゴリズムである RSA は、秘密キーを使用して署名を作成し、公開キーを使用してデジタル署名を検証します。
RSA アルゴリズムを使用するシステムは、秘密鍵で署名し、公開鍵で検証します。JWT が HMAC アルゴリズムを使用して署名され、入力として公開 RSA 鍵が使用されている場合、受信側システムは、HMAC アルゴリズムを使用して署名を検証するために、既知の公開 RSA 鍵を使用するように騙される可能性があります。
この攻撃は、受信側システムが JWT ヘッダーによるトークン認証を許可した場合に機能します。この場合、攻撃者は非対称スキームの公開鍵を対称署名スキームの共有秘密鍵として宣言しました。
JWT のセキュリティと有効性を最大限に高めるには、実装時にこれらのベスト プラクティスに従う必要があります。
JWTは従来のセッショントークンとは異なる いくつかの方法で：
JWT はステートレスであり、サーバー側のストレージを必要としません。すべての情報はトークン自体に保存されるため、サーバー ストレージが不要になり、Web アプリの要件が軽減されます。状態を管理するために、セッション トークンにはサーバー ストレージが必要になるため、これらのアプリケーションのスケーリングはより困難になります。
JWT は分散認証を可能にします。ユーザーに JWT が発行されると、正しい秘密鍵を持つどのサービスでも、中央サーバーに接続することなくトークンを検証できます。セッション トークンを使用する場合、ユーザーは通常、サーバー上に保存されているセッション データを使用して資格情報を検証する必要があります。
JWT はセッション トークンよりも多くの情報を保持できます。ユーザー ロール、権限、トークン情報、メタデータなどを含めることができます。セッション データには通常、識別子のみが含まれ、残りはサーバー上に保存されます。
JWT では機密データがユーザーのマシンに保存されるため、セキュリティに関する異なる考慮事項が必要です。暗号化、適切な署名、および秘密鍵の適切な処理が必要です。セッション トークンのセキュリティの多くは、サーバーのデータ管理に依存します。
JWT は、サーバー操作を減らすことで Web アプリケーションのパフォーマンスを向上させることができます。たとえば、データベース検索の回数を減らして、高帯域幅アプリケーションのパフォーマンスを向上させることができます。セッション トークンでは、リクエストごとに検索が必要になる場合があり、スケーリングが複雑になる可能性があります。
JWT は汎用性が高く、次のようなさまざまなシナリオに適用できます。
JWT はマイクロサービス間の通信を容易にします。JWT は秘密鍵を使用して任意のサーバーで認証できるため、アプリケーションの分散化とサービス間通信のセキュリティ確保に役立ちます。また、サーバー間でユーザー コンテキストを伝達し、共有データベースを使用せずに一貫したユーザー状態を維持するのにも役立ちます。
JWT は、モバイル アプリでのユーザー認証とセッションの管理に役立ちます。これは、接続が断続的なエリアで永続的な認証を必要とするアプリにとって特に重要です。JWT はデバイスに安全に保存され、ユーザー情報、権限、その他の情報を維持しながら、キャッシュされたリソースを使用して一定レベルのオフライン アクセスを可能にします。
JWTは、ステートレスな認証と豊富なユーザー情報を可能にすることで、APIとWebアプリケーションの構築を簡素化します。サーバー側セッションなしでAPIアクセスを認証するのに役立ちます。トークンにユーザーの役割と権限を直接含めることで、認証を簡素化します。 Zoomアプリケーション認証.
「JWT は現代のアプリケーションにとって不可欠であり、プラットフォーム間で安全かつ効率的な通信を可能にします。」
JWT は、認証とデータ交換を管理および保護するための軽量な方法を提供します。JWT は、特定のセキュリティ対策とスケーラブルなリソースを必要とする組織に適している可能性があります。
LogicMonitorの サポートセクション またはLMに参加 コミュニティのディスカッション JWT の実装とセキュリティのベスト プラクティスについて詳しくは、こちらをご覧ください。
JWT は、ステートレスな認証と承認を可能にすることで、マイクロサービス間の安全で効率的な通信を実現します。
JWT を使用すると、モバイル アプリは暗号化されたユーザー データと権限を伝送してユーザーを安全に認証できるため、サーバー側のセッション ストレージの必要性が減り、パフォーマンスが向上します。
よくある落とし穴としては、アルゴリズムの混乱、弱い秘密、安全でないクライアント側ストレージ、不適切なトークン検証などがあり、これらはすべて対処しないとセキュリティが侵害される可能性があります。
JWT はトークン形式ですが、OAuth は認証フレームワークです。JWT は、OAuth 実装内でトークンとしてよく使用されます。
トークン更新メカニズムを実装し、短期間のアクセス トークンや長期間の更新トークンなどの適切な有効期限を設定して新しいアクセス トークンを取得し、セキュリティを維持しながら継続的なアクセスを確保します。
署名されていても、JWTのペイロードとヘッダーはトークンを持つ人なら誰でもデコードできます。つまり、パスワードや個人情報といった機密情報が漏洩する可能性があるということです。機密データは常にサーバー上に保管してください。
JWTは、ユーザーの役割、権限、その他のデータをトークン自体に保持します。これにより、ユーザーの詳細を取得するためにサーバーを何度も参照する必要がなくなります。バックエンドの負荷を軽減し、アプリの応答時間を改善できます。
サーバー側で認証状態を制御したい場合は、セッショントークンを使用してください。これにより、認証の失効が容易になり、機密データの保護が強化されます。ステートレスなスケーリングを必要としないアプリにとっては、よりシンプルな選択肢となります。
JWTヘッダーでアルゴリズムを制御できるようにすると、攻撃者がそれを「none」やその他の脆弱な方法に変更でき、トークンを偽造できる可能性があります。サーバーでは常に特定の安全なアルゴリズムを強制してください。
JWTは、強化されたCookieや暗号化されたストレージなどの安全な場所に保存してください。トークンの有効期限を短くすることで、トークンの有効期間を制限してください。リスクを軽減するために、トークンのスコープを常に制限し、サーバー側で検証してください。
JWSは署名付きトークンであり、データの整合性は保護しますが、機密性は保護しません。JWEは暗号化されているため、整合性と機密性の両方を保護します。データのプライバシーを確保する必要がある場合は、JWEを使用してください。
JWTはステートレスであるため、サーバー側のブラックリストやトークンレジストリなどの追加システムがなければ、失効は困難です。有効期限を短く設定し、リフレッシュトークンを使用する方法もあります。セキュリティを強化するには、サーバーデータベースでアクティブなトークンを追跡してください。
© LogicMonitor 2025 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。
