JSONウェブトークンとは何ですか
JSONウェブトークン（略称JWT）は、この記事では、それが動作し、使用方法を説明し、最も人気のあるクロスドメイン認証ソリューションです。
最初は、クロスドメイン認証の問題である
インターネットサービスは、ユーザー認証なしで行うことはできません。通常、このプロセスは以下の通りです。
1、ユーザーがサーバーにユーザー名とパスワードを送信します。
図2に示すように、サーバ認証は、渡されたそのようなユーザの役割、ログイン時間などのような現在のセッション（セッション）内部のデータを、記憶されています。
3、ユーザーにサーバーが返すsession_idの書き込みユーザークッキー。
4.ユーザークッキー、サーバーへのsession_idバックすることにより、その後のすべての要求になります。
図5に示すように、サーバは、予め格納されたデータを見つけ、SESSION_IDを受信し、したがって、ユーザのアイデンティティを表します。
このモデルの問題は、スケーラビリティ（スケーリング）が良くない、ということです。もちろんスタンドアロンそれはサーバのクラスタ、またはクロスドメインであれば、何の問題は、
サービス指向アーキテクチャ、それがセッションを共有するデータを必要とせず、各サーバは、セッションを読むことができます。
たとえば、AとBのサイトサイトは、同社のサービスに関連付けられています。今では再訪サイトのいずれかで、ユーザのログイン限り、必要で
自動的にログインする別のウェブサイトを尋ね、どのように達成するために頼みますか？
一つの解決策は、データベースまたは他の永続化層に書き込まれたセッションデータの永続性、です。リクエストサービスの受領後、に固執していてください
要求データを。このアプローチの利点は明白な構造で、欠点は、エンジニアリングよりも大きくなっています。さらに、吊り持続性の場合は、単一障害点があります。
別のオプションは、サーバーがセッションデータは保存されませんし、すべてのデータがクライアントに格納され、サーバーへの各リクエストのバックだけです。
JWTは、このプログラムの代表です。
JWT原理
認証サーバがユーザにJSONオブジェクトのバックを生成した後、JWTの原理は、次のとおりです。
{
"姓名": "Joey",
"角色": "管理员",
"到期时间": "2020年2月14日0点0分"
}
その後、ユーザとサーバ間の通信時には、JSONオブジェクトを送り返す必要があります。サーバーは、完全にオブジェクト識別されたユーザに依存しています。
オブジェクトを生成するとき、データの改ざんからユーザーを防止するために、サーバは、署名（後述の詳細）を追加します。
サーバーは、任意のセッションデータは保存されません、それは、ステートレスなサーバになるので、比較的簡単に拡張を実現しています。
JWTのデータ構造は、
長い道のりをJWT：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4
gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
これはドットで3つのセクションに分離され、非常に長い文字列です（。）。内部JWTは一切改行されず、ここだけのためにという注意
を示すの利便性、それはいくつかの行に書き込まれます。
JWTは、順次3つのセクションが次の
ヘッダ（ヘッダ）、
ペイロード（負荷）
署名（署名された）
単一の行に：
Header.Payload.Signature
ヘッダ
ヘッダ部は、JSONオブジェクトは、メタデータJWTは次のように一般的に記載されています。
{
"alg": "HS256",
"typ": "JWT"
}
コード上に、ALGプロパティは署名アルゴリズム（アルゴリズム）を示し、HMAC SHA256（書き込みHS256）をデフォルト、標準の
属性は、トークン（トークン）タイプ（型）を示し、JWTはJWTとして書き込ま統一トークン。
最後に、JSON Base64URLアルゴリズム（後述の詳細）を使用して上記の目的は、文字列に翻訳しました。
ペイロード
ペイロードが必要とされる実際のデータ転送を格納するために使用されるJSONオブジェクトの一部です。JWTは、選択のための7つの公式の場を提供：
ISS（発行者）：発行体
EXP（有効期限）：有効期限の
サブ（件名）：テーマ
AUD（聴衆）：オーディエンス
NBF（前ではなく）：効果的な時間
に発行（IATを）：時間の問題
JTI（JWT ID）：いいえ。
公式の場に加えて、あなたも、このセクションでプライベートフィールドを定義することができます。
{
"sub": "1174051426",
"name": "Joey Tribiani",
"admin": true
}
注、JWTのデフォルトは暗号化されていない、誰でも読むことができますので、このセクションで機密情報を入れないでください。JSONオブジェクトを
文字列に変換Base64URLアルゴリズムを使用する必要があります。
署名
署名は、データ改竄を防止するため、最初の2つの部分の署名の一部です。
まず、あなたは鍵（秘密）を指定する必要があります。キーはサーバがユーザに開示することはできません知っていることです。次に、
ヘッダ指定署名アルゴリズム（デフォルトHMAC SHA256）、以下の式に従って署名を生成します。
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret
)
署名を計算した後、ヘッダは、ペイロード、署名は、3つの部分文字列を構成する（。）それぞれとの間の「ドット」部分に
パーティション、ユーザに戻すことができます。
Base64URL
述べたように、ヘッダーと文字列型アルゴリズムBase64URLのペイロード。このアルゴリズムはBase64本質的に同様とアルゴリズムが、そこにある
いくつかのマイナーな違いが。
トークン（トークン）としてJWT、（例えばapi.example.com/?token=xxxなど）いくつかのURLを置いてもよい状況。
3つの文字はBase64で+は、/、および=、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プロトコルを使用するように、送信されるべきではありません。
