JSON Webトークン
「jot（ジョット）」と発音されるJSON Webトークン（JWT）は、オープン標準（RFC 7519）であり、JSONオブジェクトとして当事者間で情報を安全に送信するためのコンパクトで自己完結型の方法を定義しています。繰り返しになりますが、JWTは標準であり、すべてのJWTはトークンですが、すべてのトークンがJWTというわけではありません。
JWTはサイズが比較的小さいため、URLやPOSTパラメーターを介して、またはHTTPヘッダー内から送信でき、すばやく伝送されます。データベースに複数回の問い合わせを行うことを避けるために、JWTにはエンティティに関するすべての必要な情報が含まれています。JWTの受信者も、トークンの検証のためにサーバーを呼び出す必要はありません。
JWTのメリット
単純なWebトークン（SWT）やSAMLトークンと比較すると、JWTには次のような使用上のメリットがあります。
コンパクト：JSONはXMLよりも冗長性が低いため、エンコードされた場合、JWTはSAMLトークンよりもサイズが小さくなります。このため、HTMLやHTTP環境で渡すにはJWTが適しています。
安全：署名を行う際、JWTはX.509証明書の形式の公開鍵/秘密鍵ペアを使用できます。またJWTは、HMACアルゴリズムを使用して共有秘密鍵で対称的に署名することもできます。さらに、SAMLトークンもJWTのような公開鍵/秘密鍵ペアを使用できますが、不明瞭なセキュリティホールを生じさせずにXMLデジタル署名を使用してXMLに署名することは、JSONに署名する場合のシンプルさと比較すると非常に困難です。JWTの署名アルゴリズムについて、詳しくお読みください。
一般的：JSONのパーサーはオブジェクトに直接マッピングできるため、ほとんどのプログラミング言語で一般的です。逆に、XMLにはドキュメントからオブジェクトへの自然なマッピングがありません。このため、SAMLアサーションよりもJWTの方が、扱いが簡単です。
処理しやすい：JWTはインターネット規模で使用されます。つまり、ユーザーのデバイス、特にモバイルでの処理が容易になります。
JWTを使用する
JWTはさまざまな方法で使用できます。
認証：ユーザーが資格情報を使ってログインに成功すると、IDトークンが返されます。OpenID Connect（OIDC）の仕様によると、IDトークンは常にJWTです。
認可：ユーザーがログインに成功すると、アプリケーションはそのユーザーに代わってルート、サービス、リソース（APIなど）へのアクセスを要求することがあります。そのためには、すべての要求でアクセストークンを渡す必要がありますが、これはJWTの形式である場合もあります。シングルサインオン（SSO）では、形式のオーバーヘッドが小さく、異なるドメイン間で簡単に使用できるという理由から、JWTが広く使用されています。
情報交換：JWTは署名が可能で、送信者が本人であることを確信できるため、当事者間で情報を安全に送信するのに適した方法です。さらに、JWTの構造自体からも、コンテンツが改ざんされていないことを確認できます。
JWTの安全性
JSONオブジェクトに含まれる情報は、デジタル署名されているため検証可能であり、信頼できます。JWTは、当事者間で機密性を確保するために暗号化することもできますが、Auth0が発行するJWTはJSON Web Signature（JWS）であり、暗号化ではなく署名が行われます。そのため、私たちは署名付きトークンに焦点を当てます。署名付きトークンは、その中に含まれるクレームの整合性を検証できますが、暗号化されたトークンはそうしたクレームを他の当事者から隠します。
一般的に、JWTは秘密鍵（HMACアルゴリズムを使用）、あるいはRSAまたはECDSAを使用した公開鍵/秘密鍵ペアで署名できます（ただし、Auth0はHMACとRSAのみをサポートしています）。トークンが公開鍵/秘密鍵のペアを使用して署名されている場合、その署名は、秘密鍵を保有する当事者だけが署名した人物であることも証明します。
受け取ったJWTを使用する前に、その署名を使用して適切に検証する必要があります。トークンの検証が正常に完了しても、そのトークンに含まれる情報が他の人物によって変更されていないことを意味するだけであることに注意してください。プレーンテキストで保存されているコンテンツを他の人物が見られなかったという意味ではありません。このため、JWTには絶対に機密情報を保存してはならず、JWTをHTTPSのみで送信する、ベストプラクティスに従う、安全で最新のライブラリのみを使用するなど、JWTが傍受されないようにその他の対策を講じる必要があります。