まず、クロスドメイン認証の問題
インターネットサービスは、ユーザー認証なしで行うことはできません。通常、このプロセスは以下の通りです。
1、ユーザーがサーバーにユーザー名とパスワードを送信します。
図2に示すように、サーバ認証は、渡されたそのようなユーザの役割、ログイン時間などのような現在のセッション（セッション）内部のデータを、記憶されています。
3、ユーザーにサーバーが返すsession_idの書き込みユーザークッキー。
4.ユーザークッキー、サーバーへのsession_idバックすることにより、その後のすべての要求になります。
図5に示すように、サーバは、予め格納されたデータを見つけ、SESSION_IDを受信し、したがって、ユーザのアイデンティティを表します。
このモデルの問題は、スケーラビリティ（スケーリング）が良くない、ということです。もちろんスタンドアロンそれはサーバのクラスタ、またはクロスドメインのサービス指向アーキテクチャーであれば、何の問題は、それがセッションを共有するデータを必要とせず、各サーバは、セッションを読むことができます。
たとえば、AとBのサイトサイトは、同社のサービスに関連付けられています。今では自動的にログに記録する別のウェブサイトを訪問し、その後、長いウェブサイトのログイン中のユーザーのように、必要とし、達成するためにどのように頼みますか？
一つの解決策は、データベースまたは他の永続化層に書き込まれたセッションデータの永続性、です。リクエストの様々なサービスの領収書は、すべての永続層にデータを要求しました。このアプローチの利点は明白な構造で、欠点は、エンジニアリングよりも大きくなっています。さらに、吊り持続性の場合は、単一障害点があります。
別のオプションは、サーバーがセッションデータは保存されませんし、すべてのデータがクライアントに格納され、サーバーへの各リクエストのバックだけです。JWTは、このプログラムの代表です。
二、JWT原則
認証サーバは、以下のように、ユーザーにJSONオブジェクトのバックを生成した後、JWTの原理は、あります。
{ "姓名": "张三", "角色": "管理员", "到期时间": "2018年7月1日0点0分" }
その後、ユーザとサーバ間の通信時には、JSONオブジェクトを送り返す必要があります。サーバーは、完全にオブジェクト識別されたユーザに依存しています。オブジェクトを生成するとき、データの改ざんからユーザーを防止するために、サーバは、署名（後述の詳細）を追加します。
サーバーは、任意のセッションデータは保存されません、それは、ステートレスなサーバになるので、比較的簡単に拡張を実現しています。
三、JWTのデータ構造
おそらく、このような実際のJWT。
これは、（中間点で非常に長い文字列である.3分割します）。内部JWTは一切改行しないことに注意してください、そしてここでの唯一の表示を容易にするために、それはいくつかの行に書き込まれます。
JWT順次三つの部分、以下のように。
- ヘッダー（ヘッド）
- ペイロード（負荷）
- 署名（署名）
行に書かれた、それは次のようです。
Header.Payload.Signature
以下は、順番に三つの部分を説明しています。
3.1ヘッダー
ヘッダ部は、JSONオブジェクト、一般的に以下のようにJWTを記述するメタデータです。
{ "alg": "HS256", "typ": "JWT" }
上記のコードは、algプロパティは、署名アルゴリズム（アルゴリズム）を表し、デフォルトHMAC SHA256（HS256を書かれた）; typ属性は、トークン（トークン）タイプ（型）を示し、記述された統一トークンJWT JWT。
最後に、JSON Base64URLアルゴリズム（後述の詳細）を使用して上記の目的は、文字列に翻訳しました。
3.2ペイロード
ペイロードが必要とされる実際のデータ転送を格納するために使用されるJSONオブジェクトの一部です。JWTは、選択のための7つの公式の場を提供します。
- ISS（発行者）：発行者
- EXP（有効期限）：有効期限
- サブ（被写体）：テーマ
- AUD（聴衆）：対象読者
- NBF（前ではなく）：効果的な時間
- IAT（で発行された）：時間の問題を
- JTI（JWT ID）：いいえ
公式の場に加えて、あなたも、このセクションでプライベートフィールドを定義することができ、以下は一例です。
{ "sub": "1234567890", "name": "John Doe", "admin": true }
注、JWTのデフォルトは暗号化されていない、誰でも読むことができますので、このセクションで機密情報を入れないでください。
JSONオブジェクトを文字列に変換Base64URLアルゴリズムを使用する必要があります。
3.3シグネチャー
署名は、データ改竄を防止するため、最初の2つの部分の署名の一部です。
まず、あなたは鍵（秘密）を指定する必要があります。キーはサーバがユーザに開示することはできません知っていることです。その後、ヘッダ内で指定署名アルゴリズムを用いて、以下の式に従って署名を生成する、（HMAC SHA256デフォルト）。
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
署名を計算した後、ヘッダ、ペイロード、署名は、3つの部分の文字列（各セクション間の「点」構成する.ユーザに返すことができる分離されている）を。
3.4 Base64URL
述べたように、ヘッダーと文字列型アルゴリズムBase64URLのペイロード。このアルゴリズムはBase64本質的に同様とアルゴリズムが、いくつかの小さな違いがあります。
トークン（トークン）としてJWT、（例えばapi.example.com/?token=xxxなど）いくつかのURLを置いてもよい状況。Base64では、3つの文字を持ち+、/そして=、URL内ので交換しなければ、特別な意味を持っています=、省略されている+置き換え-、/置き換え_。これはBase64URLアルゴリズムです。
四、JWTの使用
JWTクライアントがクッキーに保存することができ、サーバーが返すが、またのlocalStorageに保存することができ受けます。
その後、毎回クライアントとサーバの通信は、JWTを持参しなければなりません。あなたはクッキーの中に置くことができ、自動的に送信されますが、より良いアプローチは、HTTPリクエストヘッダ置くことですので、これは、クロスドメインすることはできませんAuthorizationフィールドの内部を。
Authorization: Bearer <token>
別のアプローチは、内部にデータボリュームにするとき、クロスドメイン、JWT POST要求することです。
五、JWTいくつかの機能
（1）JWTのデフォルトは暗号化されていませんが、また、暗号化することができます。オリジナルのトークンを生成した後、それは一度キーで再暗号化することができます。
暗号化なしの場合のJWT（2）は、秘密データは、JWTを書き込むことができません。
（3）JWTは、認証のために使用することができるだけでなく、また、情報を交換するために使用することができます。JWTの効果的な使用は、サーバーの数は、データベースを削減することができる照会します。
（4）JWT最大の欠点は、サーバがセッション状態は保存されませんので、トークンは当然に廃止、またはトークンの権限を変更することができない、というのです。サーバは追加のロジックを展開する場合を除きすなわち、発行JWTたら、満期日まで有効のままになります。
（5）JWT自体が開示されたときに、誰もがトークンのすべての権限を取得することができ、認証情報が含まれています。盗難を減らすために、JWTの妥当性が比較的短く設定する必要があります。より重要な権利のいくつかのために、再び使用中のユーザを認証する必要があります。
（6）不正を低減するために、HTTPプロトコルを使用してJWTコードは、HTTPSプロトコルを使用するように、送信されるべきではありません。
第六に、参照リンク
- JSONウェブトークン入門 Auth0することにより、
- （ノード+エクスプレス+パスポートJSで）JWTsを使用してセッションレス認証ブライアンManueleによって、
- JSONウェブトークンを使用する方法を学ぶ dwylにより、