JSON Web Token 使用詳解

JWT是什麼?

JSON Web Token（縮寫 JWT）是目前最流行的跨域認證解決方案。它是有三部分組成,示例如下，具體的講解如下(jwt是不會有空行的，下面只是為了顯示，便使用了換行看著比較方便)。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjMfQ.

SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

它是由一個"."號隔開、三部分組成。
第一部分是header資訊，

{
  "alg": "HS256",// 加密的演算法
  "typ": "JWT"// 加密的方式，填寫JWT
}

第二部分是Payload，有固定的六個部分和自定義資料組成,自定義資料看自己的情況需要來定義，是可以省去的。

'iss' => 'https://www.qqdeveloper.com',// 簽發人
'exp' => time() + 86400,// 過期時間(這裡的有效期時間為1天)
'sub' => '主題內容',// 主題
'aud' => '受眾內容',// 受眾
'nbf' => $time,// 生效時間
'iat' => $time,// 簽發時間
'jti' => 123,// 編號

第三部分是Signature(是對前兩部分加密得來的)。由於前兩部分是公開透明的資料，因此防止資料的篡改和洩露，我們需要加密處理。首先，需要指定一個金鑰（secret）。這個金鑰只有伺服器才知道，不能洩露給使用者。然後，使用 Header 裡面指定的簽名演算法（預設是 HMAC SHA256），按照下面的公式產生簽名。

第一部分的加密方式(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)

最終生成的就是上面很長的一段字串了。

為什麼會使用JWT

這就需要從我們傳統的認證模式來說了，傳統的認證模式是基於session和cookie來實現使用者的認證和鑑權。具體的流程模式如下圖。

2.服務端在收到客戶端的請求時，生成一個唯一的sessionid，這裡需要將該生成的session儲存在服務端,這個sessionid儲存具體的session內容，預設的是檔案儲存，當然我們可以修改具體的儲存方式，例如資料庫儲存。
3.客戶端在接受到這個sessionid時，存在cookie裡面，每次請求時攜帶該sessionid。
4.服務端在接收到客戶端的請求之後，根據客戶端傳送的sessionid來進行認證與授權。
這裡也推薦一下自己之前分享的一篇有關session於cookie的知識點。

2.服務端在收到客戶端的請求之後，生成一個唯一token，這裡需要將該生成的token儲存在服務端，至於怎麼存，可以和上面session與cookie的方式一致。也可以存在快取資料庫中，如redis，memcached。
3.服務端將該token返回給客戶端，客戶端存在本地，可以存請求頭header中，也可以存在cookie中，同時也可以存在localstorage中。
4.向服務端傳送請求時，攜帶該token，服務端進行認證或者授權。

2.服務端根據jwt的生成規則，生成一個token，並返回給客戶端，這裡服務端是不需要儲存的。
3.客戶端在接受到該token時，存在客戶端。
4.客戶端向服務端傳送請求時，服務端對請求的token進行解析，如果發現解析出來的資料和生成的資料是一致的代表是一個合法的token，則進行相應的操作。

基於session和cookie的認證和鑑權模式有什麼好與不好的地方呢？總結如下幾點：

透過上面幾張圖，我們也大致可以看得出來，基於session都是需要服務端儲存的，而JWT是不需要服務端來儲存的。針對以上幾點，總結如下：
一、缺點
1.容易遇到跨域問題。不同域名下是無法透過session直接來做到認證和鑑權的。
2.分散式部署的系統，需要使用共享session機制
3.容易出現csrf問題。

二、優點
1.方便靈活，伺服器端直接建立一個sessionid，下發給客戶端，客戶端請求攜帶sessionid即可。
2.session儲存在服務端，更加安全。
3.便於服務端清除session，讓使用者重新授權一次。

JWT與session有什麼區別呢？

JWT是基於客戶端儲存的一種認證方式，然而session是基於服務端儲存的一種認證方式。JWT雖然不用服務端儲存了，也可以避免跨域、csrf等情況。但也存在如下幾個不太好的地方。
1.無法清除認證token。由於JWT生成的token都是儲存在客戶端的，不能有服務端去主動清除，只有直到失效時間到了才能清除。除非服務端的邏輯做了改變。
2.儲存在客戶端，相對服務端，安全性更低一些。當JWT生成的token被破解，我們不便於清除該token。

如何使用JWT

這裡推薦使用GitHub上面人家封裝好的包，這裡我使用的是firebase/php-jwt，在專案中直接使用即可安裝成功。

composer require firebase/php-jwt

接下來建立一個控制器,我這裡使用的5.1的框架

use thinkController;
use FirebaseJWTJWT;

class Test extends Controller
{
    private $key = 'jwtKey';

    // 生成JWT
    public function createJwt()
    {
        $time  = time();
        $key   = $this->key;
        $token = [
            'iss' => 'https://www.qqdeveloper.com',// 簽發人
            'exp' => $time + 86400,// 過期時間(這裡的有效期時間為1天)
            'sub' => '主題內容',// 主題
            'aud' => '受眾內容',// 受眾
            'nbf' => $time,// 生效時間
            'iat' => $time,// 簽發時間
            'jti' => 123,// 編號
            // 額外自定義的資料
            'data' => [
                'userName' => '程式設計浪子走四方'
            ]];
        // 呼叫生成加密方法('Payloadn內容','加密的鍵',['加密演算法'],['加密的可以'],['JWT的header頭'])
        $jwt = JWT::encode($token, $key);
        return json(['data' => $jwt]);
    }

    // 解析JWT
    public function analysisJwt()
    {
        try {
            $key = $this->key;
            $jwt = 'eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9leGFtcGxlLm9yZyIsImV4cCI6MTU2ODA5NjE4MCwic3ViIjoiXHU0ZTNiXHU5ODk4XHU1MTg1XHU1YmI5IiwiYXVkIjoiXHU1M2Q3XHU0ZjE3XHU1MTg1XHU1YmI5IiwibmJmIjoxNTY4MDA5NzgwLCJpYXQiOjE1NjgwMDk3ODAsImp0aSI6MTIzLCJkYXRhIjp7InVzZXJOYW1lIjoiXHU3ZjE2XHU3YTBiXHU2ZDZhXHU1YjUwXHU4ZDcwXHU1NmRiXHU2NWI5In19.kHb_9Np0zjE25YE9czUEGvmFPYtqMJT9tuZzJTuMZl0';
            // 呼叫解密方法('JWT內容','解密的鍵,和加密時的加密鍵一直','加密演算法')
            $decoded = JWT::decode($jwt, $key, array('HS256'));
            return json(['message' => $decoded]);
        } catch (Exception $exception) {
            return json(['message' => $exception->getMessage()]);
        }

    }
}

透過訪問第一個方法，可以生成下圖一段字串

我們將上圖中的字串複製到第二圖中的$jwt變數,訪問第二個方法即可解析出具體的資料。