關於JWTtoken的管理問題

JWT簡介:

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

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

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

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中的,在此不談。redis

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

  解決方案:數據庫

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

相關文章
相關標籤/搜索