JSON Web Token (JWT)の使用を開始する

JSON Web Token (JWT) はオープン標準 ( RFC 7519 ) であり、JSONオブジェクトとしてエンコードされた、パーティ間で情報を安全に送信するためのコンパクトで自己完結型の方法を定義しています。この情報はデジタル署名されているため、検証することができ信頼がおけます。JWTはシークレット (HMAC アルゴリズムを使用) 、または RSA を使用した、公開/秘密鍵ペアを使用して署名できます。

この定義のいくつかの概念をさらにご説明しましょう。

• コンパクト:コンパクトなため、URL、POSTパラメーター、またはHTTP ヘッダー内で送信できます。さらに、伝送はとても高速です。
• 自己完結型:ペイロードにはデータベースへの複数回のクエリを避けるために、ユーザーに関するすべての必要な情報が含まれています。

以下は、JSON Web Token (JWT) が役立ついくつかの状況です。

• 認証 :これはJWTを使用する一般的なシナリオです。ユーザーがログインすると、後続の各リクエストにJWTが含まれ、ユーザーはそのトークンで許可されているルート、サービス、およびリソースにアクセスできるようになります。シングルサインオンはオーバーヘッドが小さく、異なるドメインのシステム間で簡単に使用できるため、現在JWTで広く使用されている機能です。
• 情報交換:JWTは、当事者間で情報を安全に送信するための優れた方法です。たとえば、公開鍵と秘密鍵のペアを使用して署名できるため、送信者が本人であることを確認できます。さらに、ヘッダーとペイロードを使用して署名が計算されるため、コンテンツが変更されていないことも確認できます。

JWTは、ドット ( . ) で区切られた次の3つの部分で構成されています。

• ヘッダー
• ペイロード
• 署名

したがって、JWTは通常、次のようになります。

xxxxx.yyyyy.zzzzz

詳しくみてみましょう。

ヘッダー

ヘッダーは通常JWTであるトークンのタイプと、HMAC SHA256またはRSAなどの、ハッシュアルゴリズムの 2つの部分で構成されています。

例 :

{
  'alg':'HS256',
  'typ':'JWT'
}

次に、このJSONは Base64Url でエンコードされ、JWTの最初の部分を形成します。

ペイロード

トークンの2番目の部分は、クレームを含むペイロードです。クレームは、エンティティ (通常はユーザー) と、追加のメタデータに関するステートメントです。クレームには登録済み、パブリック、およびプライベートの3種類があります。

• • 登録済みクレーム:これらは、必須ではありませんが推奨されている、事前定義されたクレームのセットです。便利で相互運用可能な一連のクレームを提供すると考えられています。iss (発行者)、exp (有効期限)、sub (サブジェクト)、aud (オーディエンス) などがあります。

JWTはコンパクトに設計されているため、クレーム名はわずか 3文字であることに注意してください。

• パブリッククレーム:JWTを使用するユーザーは、これを自由に定義できます。ただし、衝突を回避するにはIANA JSON Web Token (JWT) レジストリで定義するか、衝突に強い名前空間を含むURIとして定義する必要があります。
• プライベートクレイム:これらは、使用に同意する関係者間で情報を共有するために作成されたカスタムクレームです。

ペイロードの例は次のとおりです。

{
  'sub':'1234567890',
  'name':'John Doe',
  'admin': true
}

その後、ペイロードはBase64Urlエンコードされて、JWTの2番目の部分を形成します。

署名

署名部分を作成するには、エンコードされたヘッダー、エンコードされたペイロード、シークレット、ヘッダーで指定されたアルゴリズムを取得し署名する必要があります。

たとえば、HMAC SHA256アルゴリズムを使用する場合、署名は次のように作成されます。

HMACSHA256(
  base64UrlEncode(header) + '.' +
  base64UrlEncode(payload),
  secret)

JWTの送信者が本人であることを確認し、メッセージが途中で変更されていないことを確認するために、署名は使用されます。

すべてをまとめる

出力はドットで区切られた3つのBase64文字列であり、HTMLおよびHTTP環境で簡単に渡すことができ、SAML などのXMLベースの標準に比べてコンパクトです。

以下は、以前のヘッダーとペイロードがエンコードされ、シークレットで署名されているJWTを示しています。

JWTの概念を実際に試してみることができるjwt.ioをご参照ください。jwt.ioを使用すると、JWTをデコード、検証、および生成することができます。

認証ではユーザーが資格情報を使用して正常にログインすると、JSON Web Token (JWT)が返されます。トークンは資格情報であるため、セキュリティの問題を防ぐために細心の注意を払う必要があります。一般的に、トークンは必要以上に長く保持するべきではありません。

また、セキュリティが不十分なため、機密性の高いセッションデータをブラウザストレージに保存しないでください。

ユーザーが保護されたルートにアクセスしたいときは、JWTを送信する必要があります。通常は、Bearer スキーマを使用して Authorization ヘッダーで送信します。したがって、ヘッダーの内容は次のようになります。

認証 :Bearer <token>

ユーザーの状態がサーバーのメモリに保存されないので、これは、ステートレスな認証メカニズムとなります。サーバーの保護されたルートは、Authorizationヘッダーに有効なJWTがあるかどうかを確認し、存在する場合、ユーザーは許可されます。JWTは自己完結型であるため、必要なすべての情報がそこにあり、データベースに行ったり来たりする必要がなくなります。

これにより、ステートレスなデータAPIを完全に頼ることができ、ダウンストリームサービスへのリクエストさえ行うことができます。Cookieを使用しないので、Cross-Origin Resource Sharing (CORS) は問題にならず、どのドメインがAPI を提供しているかは関係ありません。

JSON Web Tokens (JWT) の利点について、Simple Web Tokens (SWT)およびSecurity Assertion Markup Language Tokens (SAML)と比較してご説明しましょう。

JSONはXMLほど冗長ではないため、エンコードするとサイズが小さくなります。 JWTはSAMLよりもコンパクトになります。これにより、JWTはHTMLおよびHTTP環境で渡されるのに適した選択肢になります。

セキュリティ上の観点でいうと、SWTは、HMACアルゴリズムを使用した、共有シークレットによってのみ対称署名できます。JWTおよびSAMLトークンは、X.509証明書の形式で、公開鍵と秘密鍵のペアを使用して署名することもできます。しかし、セキュリティホールを隠ぺいせずに、XMLデジタル署名を使用してXMLに署名することは、JSONへの署名のシンプルさに比べて非常に複雑です。

JSONパーサーは、ほとんどのプログラミング言語で一般的です。オブジェクトに直接マッピングされるため、XMLにはドキュメントからオブジェクトへの、自然なマッピングがありません。そのため、SAMLアサーションよりもJWTを使用する方が簡単になります。

使い方についていうと、JWTはインターネット規模で使われています。これは複数のプラットフォーム、特にモバイルでの、JWTのクライアント側処理の容易さを強調しています。

Auth0では、認証プロセスの結果としてJWTを発行します。ユーザーがAuth0を使用してログインすると、JWTが作成され、署名され、ユーザーに送信されます。Auth0は、HMACアルゴリズムとRSAアルゴリズムの両方を使用したJWTの署名をサポートしています。このトークンは、保護されたルートとリソースへのアクセスを許可するAPI で、認証および承認するために使用されます。

また、当社は、従来使われている不透明なAPIキーの代わりに、JWTを使用してAuth0のAPI v2で認証と承認を実行します。認可に関しては、JSON Web Token (JWT) はきめ細かなセキュリティを可能にします。つまり、トークンで特定のアクセス許可のセットを指定できるので、デバッグが容易になります。