關於JWTtoken的管理問題

JWT簡介:

    　Json web token (JWT), 是爲了在網絡應用環境間傳遞聲明而執行的一種基於JSON的開放標準。由於網絡上有不少關於jwt的詳細介紹了，因此我這裏就再也不贅述。可是JWT的大概仍是要簡要講一下的。

　　衆所周知，在如今的互聯網世界中，愈來愈多的網站之間由於業務關係須要頻繁的跨域互相訪問，可是因爲HTTP協議的同源策略，在跨域訪問中如何攜帶用戶我的信息認證就是一個大問題了。爲了安全，cookie是隻能在同域名下才能做用，這也使以前一直經常使用的session和cookie來保持用戶狀態的機制在這種狀況下無能爲力。而JWT也由此應運而生，愈來愈多的應用在了大型網站的單點登陸中了。

　　簡單敘述一下jwt的構成，jwt總共由3個部分構成，分別是header頭部，用來存儲該token的加密方式和一些簡介。payload部分，用來存儲用戶的非敏感信息和一些由於業務須要所需的數據。而header和payload都是json格式的數據，經過能夠互相轉化的base64轉碼成字符串，這也是爲何在token中不要攜帶用戶敏感信息的圓心。最後的部分是signature,它由保存在公司內部的密鑰和前面的header還有payload經過header部分裏聲明的加密方式以及一些加鹽操做加密而成。三個部分分別用 . 隔開，最終造成header.payload.signature這個形式。

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

base64(header)  --> eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

payload:
{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

base64(payload)  --> eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

最終組成 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
    

　　JWT是在用戶註冊或者登錄以後經過服務器簽發給客戶端，大部分客戶端經過localstorage來存儲token，這樣就能夠在前端發起請求時主動攜帶上token，而後服務器接收以後經過驗證來判斷該用戶的認證信息了。也有少部分客戶端是將token存儲在cookie中的，在此不談。

　　那麼今天要談的問題來了，由於token是存儲在客戶端的，那麼就表示着一旦服務器在簽發token以後，除了等待token到時限失效以外失去了管控token的能力。一旦客戶端token丟失等狀況發生，就會產生用戶安全問題。

　　解決方案:

　　服務器在用戶第一次登錄或者註冊成功後在簽發token時能夠給該token配置一個token_id，並保存到服務器的redis或者mysql數據庫中。用戶在訪問時若是攜帶了token便須要先通過token_id的校驗，再進行後面用戶身份信息的校驗。一旦用戶發起安全申請，便當即刪除服務器保存的token_id，而用戶攜帶的token在token_id這個步驟的校驗失敗以後便會跳轉到登陸界面，由服務器從新簽發token。