記事ディレクトリ

1.トークンベースの認証方法
2.JWT
- 2.1ヘッダー
- 2.2ペイロード
2.3signatrue
3.Webセキュリティ

Tokenの場合、Facebook、Twitter、Google、Githubなどの多くの大規模なWebサイトで使用されます。従来の認証方法と比較して、Tokenはよりスケーラブルで安全であるため、Webアプリケーションでの使用に非常に適しています。モバイルアプリ

1.トークンベースの認証方法

Tokenに基づく認証方法では、ユーザーのログイン記録をサーバー側に保存する必要はありません。おおよそのプロセスは次のとおりです。

クライアントはユーザー名とパスワードを使用してログインを要求します。
サーバーは、ユーザー名とパスワードを確認する要求を受け取ります。
検証が成功すると、サーバーは1つを発行しToken、これをクライアントにToken送信します。
クライアントがそれを受け取っToken た後、それはin CookieやLocal Storageinなどに保存できます。
クライアントがサーバーにリソースを要求するたびに、サーバーによる署名が必要Tokenです。
サーバーはリクエストを受信し、クライアントリクエストに含まれるデータを検証します Token。検証が成功すると、サーバーはリクエストされたデータをクライアントに返します。

2.JWT

検証を実装する方法はたくさん Tokenあり、いくつかの標準的な方法があります。たとえばJWT、次のように読みます。jotこれは、次のことを意味しますJSON Web Tokens 。JWT標準Tokenには3つの部分があります：
1。 header（ヘッダー）、ヘッダー情報には主に（パラメータータイプ– JWT、署名アルゴリズム– HS256）
2. poyload（ロード）、ロードは基本的に保存したい情報です（情報が公開され、機密データをペイロードに追加しないでください）
3. sign（署名）、署名の機能は、悪意のあるデータの改ざんを防ぐことです

中央はドットで区切られ、どちらもBase64エンコーディングを使用しているため、実際のトークンは次のようになります。
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc

2.1ヘッダー

Headerこの部分は主に2つの部分で構成され、1つはTokenのタイプで、もう1つは使用されるアルゴリズムです。たとえば、次のタイプはJWT使用されるアルゴリズムHS256です。

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

上記のコンテンツはBase64、のため、次のようになります。
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

2.2ペイロード

PayloadTokenの特定のコンテンツがあり、その一部は標準フィールドであり、他の必須コンテンツを追加することもできます。以下は標準フィールドです。

iss：発行者、発行者
サブ：件名、件名
aud：オーディエンス、オーディエンス
exp：有効期限、有効期限
nbf：前ではない
iat：リリース時に発行
jti：
以下のようなJWT IDは、発行者Payload、有効期限、および2つのカスタムフィールドを使用します。1つはで、もう1つはです。issexpnameadmin

{
    
    
    "iss" : "csdn.net",
    "exp" : "201511205211314",
    "name" : "维C果糖",
    "admin" : true
}

Base64エンコーディングを使用すると、次のようになります。
eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ

2.3signatrue

JWTの最後の部分は Signature、この部分が3つの部分で構成されており、最初 Base64にheader 和 payload暗号化され、次に暗号化アルゴリズムで暗号化されます。暗号化する場合は、1つを入力する必要がありSecretます。これは、サーバーに秘密裏に保存されるパスワードに相当します。。

header
payload
secret
var encodedString = base64UrlEncode(header) + "." + base64UrlEncode(payload); 
HMACSHA256(encodedString, 'secret');

処理後は次のようSwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc
になります。サーバーによって生成され、クライアントに送信される最後のトークンは次のようになります。
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc

クライアントがこれTokenをすると、保存され、次回サーバーにリクエストを送信するときに一緒に取得されますToken。サーバーはこれを受け取りToken、それを検証し、通過後にクライアントが必要とするリソースを返します。

3.Webセキュリティ

トークン、私たちはそれを「トークン」と呼びます、その最大の特徴はランダム性と予測不可能性です。通常のハッカーやソフトウェアはそれを推測できません。それで、トークンは何をしますか？原則は何ですか？

トークンは通常、次の2つの場所で使用されます。

フォームの再送信を防ぐ
アンチCSRF攻撃（クロスサイトリクエストフォージェリ）

どちらも原則としてによってsession token 達成ます。クライアントがページを要求すると、サーバーは乱数を生成し、をTokenにToken配置しsession 、クライアントに送信します（通常はフォームを作成します）。次回クライアントがリクエストを送信すると、フォームと一緒にサーバーに送信されます。Tokenhidden Token

次に、「Anti CSRF攻击」に適用されると、サーバーは値を検証して、のToken値sessionと等しいかどうかを判断Tokenします。等しい場合は、要求が有効で偽造されていないことを証明できます。ただし、「フォームの繰り返し送信を防ぐ」に適用した場合、サーバー側での最初の検証が同じsessionになった後、の Token値が更新されます。ユーザーが繰り返し送信すると、ユーザーが送信するため、2回目の検証判断は失敗します。 Nothingのフォームは変更されましたが、サーバーToken側で変更されました。sessionToken

上記のsessionアプリケーションは比較的安全ですが、面倒とも呼ばれます。同時に、複数のページと複数のリクエストがある場合 Tokenは、同時に複数のページを生成する方法を採用する必要があります。これにより、より多くのリソースを消費し、実行効率。したがって、代わりに認証情報をcookie保存するsession Token。たとえば、「重複提出」を扱う場合、最初の提出後、提出された情報が書き込まcookieれます。2回目の提出が行われると、cookieすでに提出レコードがあるため、2回目の提出は失敗します。ただし、cookie ストレージにはアキレス腱があります。Cookieがハイジャックされた場合（XSS攻撃はユーザーのCookieを簡単に取得できます）、別のゲームが終了すると、ハッカーは直接CSRF 攻撃をます。したがって、安全性と効率は相対的であり、特定の問題が詳細に分析されます！

また、「追加するtokenがsession追加され tokenますが、サーバーtoken は検証を行わないため、予防的な役割はまったくありません。また、データベースに変更を加えた追加、削除、および変更操作をtoken 検証。クエリ操作の場合、token攻撃者tokenがないでくださいCSRF。しかし、攻撃者がそれを取得できないわけではなく、 token攻撃のコストが増加するだけです。

トークンの詳細については、この記事を読むだけで十分です。