目錄
一 token 介面改造
二 token 有效期可配
三 上課期間 token 不過期
四 老版本 APP 不崩潰
五 密碼變更，token 失效
六 頒發、續約 token 介面安全性
七 token 簽發可控
八 token 認證介面壓測
JWT 實作 token 認證講述了 JWT一些基本概念，使用JWT token 的優缺點以及使用需要注意的問題，本章主要講述在使用 JWT token 程序中遇到的問題以及解決方案，
一 token 介面改造
token 是什么？token 是用戶登錄的時候頒發的，
改造場景：內網有一些介面是通過 token 來獲取用戶資訊，這個是不合理的，
我的理解： token 是用來認證用戶的，應該在外網之間進行流轉；內網之間流轉的應該是各種業務 id，
解決方案：獲取用戶資訊應該使用 user_id，既然能拿到 token，說明 token 經過了認證服務，那認證服務會回傳 user_id，
二 token 有效期可配
我們在生成 access_token、refresh_token 的時候會設定有效期，假設 access_token 有效期為2小時，refresh_token 為24小時，測驗人員在測驗功能的時候總不能等待
2小時或者24小時吧，那如何來解決，有效期太長的問題呢？為了提高測驗效率，做成 access_token、refresh_token 都是可配置的，比如說1分鐘過期、5分鐘過期都是可以的，
三 上課期間 token 不過期
公司有一個業務場景是學生上課，那如何保證學生上課期間 token 失效、退登的情況不會發生？一旦發生 token 失效、退登的情況很容易導致用戶體驗差，產生各種投訴，
產生這種問題的根本的原因是上課期間 token 失效，針對這種情況我們只需要保證 token 在上課期間不會失效就行了，比如我們可以設定 token 失效時間為凌晨，凌晨孩子都睡了，
四 老版本 APP 不崩潰
在頒發 JWT token 的時候，會出現 JWT token、老 token 同時存在的問題；且 JWT token 有續約流程，老 token 是沒有的，由于 APP 登錄使用的是 h5 頁面，如果頒發 JWT token，
一旦 JWT token 過期，走續約流程，APP 很容易崩潰，如何能夠保證 APP 不崩潰呢？只需要保證 APP 老版本頒發老 token、新版本頒發 JWT token，那如何保證呢？由于登錄是 h5
頁面，前端做版本控制，后端配合前端下發 JWT token、老 token，也就是說前端告訴我下發 JWT token，我就下發 JWT token；前端告訴我下發老 token，我就下發老 token，
五 密碼變更，token 失效
由于 JWT token 是分布式的，也就是說如果不做其他的事情的話，密碼變更，JWT token 是不會生效的，那如何能保證密碼變更，JWT token 失效呢？
一開始的假設是將密碼放置到 JWT token 的 payload 里面，這種方式相當于密碼暴露到外面有一定的風險，后來想著是在 JWT token 里面添加密碼變更時間戳，什么意思呢？
假設說今天給用戶頒發的 JWT token 版本是 v1，明天用戶修改了密碼，之后登錄版本的 JWT token 版本是 v2，則 v2 之前的版本 v1 都將失效，如此，才能做到密碼變更， JWT token 失效，
六 頒發、續約 token 介面安全性
頒發 token、續約 token 兩個介面屬于敏感介面，如何能夠保證這兩個介面的安全性？或者說呼叫這兩個介面是需要白名單的，
這塊我們使用了介面的 API 簽名和驗簽機制，只有特定的服務才能呼叫我們的頒發 token、續約 token 兩個介面，
七 token 簽發可控
由于是頒發 JWT token，如何保證風險可控呢？首先，我們這塊針對 token 下發做了一個開關，隨時能將下發新 token 功能下線；
其次，為了一點點推進頒發 JWT token ，我們這塊針對 mobile （userId）-> appId 進行灰度簽發，
八 token 認證介面壓測
由于是 JWT token，且認證服務壓力挺大的，為了保證系統的穩定性，這塊需要對認證 JWT token 介面進行壓測，
微信公眾號：「新猿一馬」，微信掃一掃，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/243964.html
標籤：其他
上一篇：Linux與網路服務（一）網路服務相關概念通俗解釋（科普向）
下一篇：2021，新開始，新起點