20210819jwt的具體流程與專案接下來該怎麼做

好文章：

標頭檔案：一文講解JWT使用者認證全流程

先了解一個單詞：

scopes，百度被翻譯成”範圍，領域“，其實他的含義是”使用者所擁有的角色（許可權組）“

進入正題：

其實當我拿到了wxUserinfo和zwUser後我就可以使用jwt來繼續之後的工作了：

將使用者名稱與auth，imei，gps揉進token（實際操作時或許會是個類似token的東西）返回給客戶端，客戶端在開啟flutter網頁時會把token發給服務端從而拿到物理節點的具體資訊，從而徹底實現業務需求

(我這裡故意忽略了token驗證使用者的環節，後續會說明詳細原因)

需要先探討另一個問題：

假如是如下的使用場景：某使用者的機房有10臺機器，每臺上都貼有微信公眾號的識別二維碼，10臺一起出現了問題

當用戶掃第一臺時手動同意了wxOauth2協議後，根據目前的伺服器業務邏輯使用者掃第二臺，3，4，5都需要重複手動在次同意wxOauth2協議，使用者體驗極差

解決此問題需要藉助wxOauth2技術棧自身的token機制，儲存使用者這”已經同意過wxOauth2協議“的狀態，從而不會讓每次使用都要再次進行全新的驗證流程

因此可以說，真正能用於生產的業務邏輯是必須包含token邏輯的：

真正的第一步應該是先檢視客戶端快取，是否存在wxOauth2。token，有的化直接透過

var userInfo *wxoauth2。UserInfo

url =“https：//api。weixin。qq。com/sns/userinfo？”+

“access_token=”+accessToken。AccessToken+//擁有過期機制

“&openid=O”+accessToken。OpenId+

“&lang=zh_CN”

res = http。NewRequest（“POST”， url， nil）

這一步本身就用到了token，我不得不繼續完善這裡程式碼邏輯以及上面重定向api的程式碼邏輯，整合jwt邏輯，但是如果我只想調通並不用於生產環境的話，那還是可以瞎用以下的，可是我不是很喜歡這種狀態

其實對於RedirectToWxOauth2這個api來說，正確的業務流程或許是這樣的：

真正的第一步是檢查本地快取中的token欄位，之後的邏輯大致會有如下分支：

1。完全成功的話（有token且access_token未過期），我就可以用token內部的openid欄位拿到最終實體（wxuserinfo等），然後就直接跳轉到flutter頁面

2。部分成功的話（有token且access_token過期，ref_token未過期），那就先去拿新的access_token後再去拿最終實體，再跳轉到flutter頁面

3。不成功的話（無token或acc_token、ref_token均過期）那才需要先重定向wxOauth2頁面

這裡再次深化理解了token：

即使是過期的token也能從中拿到有效的且可以從資料庫呼叫資訊的openid，但是這裡就體現出了伺服器透過過期機制把過期的登入操作主動拒絕了

微信的官方文件也教了怎麼去重新整理acctoken：

第三步：重新整理access_token（如果需要）

由於access_token擁有較短的有效期，當access_token超時後，可以使用refresh_token進行重新整理，refresh_token有效期為30天，當refresh_token失效之後，需要使用者重新授權。

請求方法

獲取第二步的refresh_token後，請求以下連結獲取access_token：

https：//

api。weixin。qq。com/sns/o

auth2/refresh_token？appid=APPID&grant_type=refresh_token&refresh_token=REFRESH_TOKEN

這部分操作未來也必然會出現在RedirectToWxOauth2中

微信開放文件

細節問題：驗證token是否過期應該是服務端做還是客戶端做？

答：由服務端來做，因為就算客戶端設計了過期驗證，服務端基於信任問題（比如客戶端是外包出去的）還是需要設計，因此就讓服務端來實現吧。

相關文章：

客戶端網路併發請求中Token失效處理方案

至此擁有了更紮實的思路