jwt是什么蛇耀？
jwt是一種session信息存儲方案，單點登錄和是否用jwt沒關(guān)系唇兑，jwt也是和系統(tǒng)內(nèi)的流程一致酒朵，不一樣的地方就是將session數(shù)據(jù)放到了前端。JWT 的最大缺點是扎附，由于服務(wù)器不保存 session 狀態(tài)蔫耽，因此無法在使用過程中廢止某個 token，或者更改 token 的權(quán)限留夜。也就是說匙铡，一旦 JWT 簽發(fā)了，在到期之前就會始終有效碍粥，除非服務(wù)器部署額外的邏輯鳖眼。
是否有CSRF風險？
有嚼摩。
- 可以加
Access-Control-Allow-Origin來控制可以跨域請求的頁面 - 跳回到子系統(tǒng)的時候钦讳，后臺可以返回
token，所有請求都需要帶上token驗證枕面。
優(yōu)化空間
登錄成功后現(xiàn)在是訪問authority/user/redirect由后端進行302跳轉(zhuǎn)到子系統(tǒng)redirect路由愿卒。這是因為之前到方案是需要后臺寫cookie到子系統(tǒng)，直接跳轉(zhuǎn)到子系統(tǒng)頁面上潮秘。改成了現(xiàn)在這樣琼开。但是依照現(xiàn)在的方案的話，沒有必要再走一次302.直接在登錄接口返回ticket唇跨，由前端帶上ticket直接訪問子系統(tǒng)的redirect路由稠通，該路由再返回html，執(zhí)行location.href=要跳往的路徑买猖「拈伲可以少一次302跳轉(zhuǎn)，減少loading時長玉控。
cookie有同源策略飞主，為什么不同域名訪問cookie對應(yīng)domain時都會攜帶上該cookie？
對cookie同源策略理解有問題高诺，cookie的同源策略指的是訪問不同域的資源時碌识，瀏覽器允不允許攜帶cookie，和當前頁面域名沒有關(guān)系虱而。比如A域名下訪問了B域名的接口筏餐，會帶上B域名下的cookie，但不會帶上C域名下的cookie牡拇。
為什么需要單點登錄魁瞪？
- 用戶希望登錄一個系統(tǒng)后穆律，登錄其他系統(tǒng)不想再登錄一遍。
- 而且在私有化部署時导俘，各子域需要部署各自的登錄模塊峦耘。前后端代碼都是用的各自的，不便于維護旅薄。
-
chrome辅髓、firefox等瀏覽器支持第三方cookie，ie和safari不支持少梁。這就導致我們不能共用一個登錄域下的cookie洛口。
單點登錄的整體流程
子系統(tǒng)融合時各系統(tǒng)獲取登錄態(tài)的問題
之前公司各個子系統(tǒng)各自獨立，公司發(fā)展凯沪，同事客戶也希望購買多個產(chǎn)品時绍弟，應(yīng)該只有一個系統(tǒng)而不需要私有化部署多套系統(tǒng)。
系統(tǒng)融合時著洼，原來的計劃是融合后的菜單中，子菜單中為各個子系統(tǒng)而叼，子系統(tǒng)內(nèi)的請求還是走各自的系統(tǒng)的接口身笤。出現(xiàn)的問題是在統(tǒng)一的登錄中心登錄完成跳回到系統(tǒng)時(此時寫cookie到系統(tǒng)域名下)，如果請求不同菜單(也就是不同子系統(tǒng)中的服務(wù))葵陵，會出現(xiàn)請求不同域?qū)е潞笈_無法獲取到種在當前系統(tǒng)下的cookie液荸，后臺也就無法判斷當前用戶是否登錄。
業(yè)內(nèi)常見的做法是登錄成功后寫入到主域下脱篙，各個子系統(tǒng)分別在各子域中娇钱，這樣子域就能拿到主域的cookie，因為我們的系統(tǒng)是私有化部署绊困，使用時都是ip文搂，也就不存在主域的概念。無法使用這個辦法秤朗，另外一個辦法后臺寫cookie時煤蹭，httponly設(shè)為false，由前端來獲取到當前域下寫入的cookie取视，請求不同子系統(tǒng)時作為參數(shù)帶上硝皂。不過這樣安全性就會降低。
目前的做法還是走反向代理作谭，走統(tǒng)一的接口地址稽物，由后臺來轉(zhuǎn)發(fā)各子系統(tǒng)下的請求，統(tǒng)一前綴來作區(qū)分折欠。
在登錄中心登錄成功后如何寫cookie到子系統(tǒng)域名下贝或？
方案一：
- 前端重定向到子系統(tǒng)吼过，帶上登錄成功后下發(fā)的ticket，子系統(tǒng)前端請求后臺傀缩，將該ticket帶上那先。
- 后臺拿到該ticket后調(diào)用authority進行校驗。如果成功就寫登錄cookie到子系統(tǒng)域名下赡艰。
- 子系統(tǒng)拿到請求結(jié)果再渲染對應(yīng)資源售淡。這種方式簡單，但有個缺點是每個子系統(tǒng)接入都得重寫一遍該邏輯慷垮。
方案二：
- 約定一個固定的子系統(tǒng)跳轉(zhuǎn)地址揖闸，各子系統(tǒng)后臺接入sdk 后，每個請求都會先經(jīng)過該sdk料身，sdk監(jiān)聽該固定地址汤纸。
- 在登錄中心登錄成功后，前端請求authority下的一個地址芹血，返回結(jié)果為302贮泞，并且寫cookie到登錄中心域名下，重定向地址為子系統(tǒng)下的固定地址幔烛，并帶上ticket啃擦。
- sdk監(jiān)聽到該請求后，再次返回302 重定向地址到子系統(tǒng)真實頁面饿悬，并將ticket寫入到子系統(tǒng)cookie中令蛉。(這里不能返回302，在各瀏覽器中同時返回302和cookie不能寫入成功狡恬，項目中的解決方案是狀態(tài)碼還是為200珠叔，資源返回html，由html中js來做跳轉(zhuǎn))
- nginx則轉(zhuǎn)發(fā)到對應(yīng)的機器目錄下弟劲，返回對應(yīng)的靜態(tài)資源祷安。
當一個子系統(tǒng)登錄成功后，直接訪問另外一個子系統(tǒng)兔乞，發(fā)生了什么辆憔？
首先會直接拿到前端資源并發(fā)起請求，如果請求響應(yīng)為登錄失效报嵌，則前端跳轉(zhuǎn)頁面到登錄中心某一地址虱咧，【注意】這時候的請求就會帶上登錄中心頁面的cookie，后臺校驗發(fā)現(xiàn)cookie有效锚国，那么會返回302響應(yīng)腕巡，戴上ticket跳回之前約定好的子系統(tǒng)固定地址，sdk監(jiān)聽到該請求后如果ticket有效血筑，那么就回到方案二中的步驟3绘沉，最后跳回到子系統(tǒng)煎楣。
