基於Token認證的多點登入和WebApi保護

2021-09-19 21:08:09 字數 2307 閱讀 9996

原文 基於token認證的多點登入和webapi保護

一天張三,李四,王五,趙六去動物園,張三沒買票,李四製作了個假票,王五買了票,趙六要直接fq進動物園

到了門口,驗票的時候,張三沒有買票被拒絕進入動物園,李四因為買假票而被補,趙六被執勤人員抓獲,只有張三進去了動物園

後來大家才知道,當乙個使用者帶著自己的資訊去買票的時候,驗證自己的資訊是否正確,那真實的身份證(正確的使用者名稱和密碼),驗證通過以後通過身份證資訊和票據列印時間(使用者登入時間)生成乙個新的動物園參觀票(token令牌),給了使用者乙個,在動物園門口也儲存了票據資訊(相當與客戶端和服務端都儲存乙份),在進動物園的時候兩個票據資訊對比,正確的就可以進動物園玩了

這就是我理解的token認證.當然可能我的比喻不太正確,望大家多多諒解

下面是我們在服務端定義的授權過濾器

思路是根據切面程式設計的思想,相當於二戰時期城樓門口設立的卡,當使用者想api發起請求的時候,授權過濾器在api執行動作之前執行,獲取到使用者資訊

如果發現使用者沒有登入,我們會判斷使用者要訪問的頁面是否允許匿名訪問

使用者沒有登入但是允許匿名訪問,放行客戶端的請求

使用者沒有登入且不允許匿名訪問,不允許通過,告訴客戶端,狀態碼403或401,請求被拒絕了

如果發現使用者登入,判斷使用者的良民證(token令牌)是真的還是假的

使用者登入,且良民證是真的,放行

發現良民證造價,抓起來,不允許訪問

當然,這裡可以加許可權,驗證是否有某個操作的許可權

好了,服務端有驗證了,客戶端也不能拉下啊,客戶端使用了動作過濾器,在使用者操作之前或使用者操作之後驗證登入資訊(這裡可以加許可權,驗證是否有某個操作的許可權)  

客戶端驗證思路和服務端驗證差不多

下面是客戶端驗證**:

但是有良民證也不能也不能無限制的待在城裡啊,我們做了乙個時效性,在城市裡什麼時也不做到達一定的時長後得驅逐出城啊(類似與遊戲中的掛機超過一定時間後t出本局遊戲)

在這裡使用的redis記錄良民證(token),思路是使用者登入之後生成的新的token儲存在redis上,設定儲存時間20分鐘,當有使用者有動作之後更新redis儲存有效期

下面是服務端驗證token的,token有效,從新寫入到redis

以上就是token認證

現在說說單點登入的思路

李四也登入了qq123456,qq資訊是一致的,但是qq登入時間不同,生成了乙個新的token,在儲存的時候發現redis裡已經存在這個qq的鍵了,說明這是已經有人登入了,在這裡可以判斷是否繼續登入,登入後新的token資訊覆蓋了張三登入qq生成的token,張三的token失效了,當他再次請求的時候發現token對應不上,被t下線了

但是有乙個人用手機登入qq 123456了,就會覆蓋redis中鍵為123456_手機的token資訊,導致原先登入那個人的資訊失效,被強制下線

來展示**

判斷是否可以登入

客戶端型別實體

這是我們的客戶端型別:

獲取token需要的使用者資訊和登入時間的實體model

這是我們的使用者model

生成token用的實體

登入成功,通過jwt非對稱加密生成token

下面是jwt加密和解密的**

將獲取到的token儲存到redis

基於Token認證的多點登入和WebApi保護

原文 基於token認證的多點登入和webapi保護 一天張三,李四,王五,趙六去動物園,張三沒買票,李四製作了個假票,王五買了票,趙六要直接fq進動物園 到了門口,驗票的時候,張三沒有買票被拒絕進入動物園,李四因為買假票而被補,趙六被執勤人員抓獲,只有張三進去了動物園 後來大家才知道,當乙個使用者...

基於Token的認證和基於宣告的標識

openid解決跨站點的認證問題,oauth解決跨站點的授權問題。認證和授權是密不可分的。而openid和oauth這兩套協議出自兩個不同的組織,協議上有相似和重合的之處,所以想將二者整合有些難度。好在openid connect作為openid的下一版本,在oauth 2.0的協議基礎上進行擴充套...

認證和SSO 五 基於token的SSO

1.1 修改 方法,獲得到token後,由存放到session改為存放到cookie 方法 接收認證伺服器發來的授權碼,並換取令牌 param code 授權碼 param state 請求授權伺服器時傳送的state 將token放到session中 token authresult.getbod...