原文 基於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...