微服務(wù)認(rèn)證鑒權(quán)解決方案
微服務(wù)結(jié)構(gòu)示意
服務(wù)鑒權(quán)示意
微服務(wù)架構(gòu)中推薦采用無狀態(tài) API 模式恩闻，主要有兩種方案比較普遍坤学。其中 OAuth2.0 能夠完全滿足。此外 JWT 除了不能滿足 SSOff(一次登出全部登出) 外款违，其他都能滿足伍纫，且是所有方案里最為簡便輕巧的一個(gè)，可通過搭配 API 網(wǎng)關(guān)來滿足 SSOff 特性的要求彻亲，因此 JWT + API 網(wǎng)關(guān)也是一個(gè)推薦的方案孕锄。
Oauth2
- OAuth2.0 是業(yè)內(nèi)成熟的授權(quán)登錄解決方案， OA2.0 提供了 4 種授權(quán)模式苞尝，能夠適應(yīng)多種場景，作為基于令牌的安全系統(tǒng)宦芦，可以廣泛用于需要統(tǒng)一身份認(rèn)證和授權(quán)的場景宙址。
JWT+API 網(wǎng)關(guān)
- JWT（JSON Web Token）是一種簡潔的自包含的 JSON 聲明規(guī)范，因其分散存儲的特點(diǎn)而歸屬于客戶端授權(quán)模式调卑，廣泛用于短期授權(quán)和單點(diǎn)登錄抡砂。由于 JWT 信息是經(jīng)過簽名的大咱，可以確保發(fā)送方的真實(shí)性，確保信息未經(jīng)篡改和偽造注益。但由于其自包含的客戶端驗(yàn)簽特性碴巾，令牌一經(jīng)簽發(fā)，即無法撤銷丑搔，因此單純采用 JWT 作為統(tǒng)一身份認(rèn)證和授權(quán)方案無法滿足帳號統(tǒng)一登出和銷毀厦瓢、帳號封禁和解除這幾種類型的需求。
主流認(rèn)證鑒權(quán)的兩種方式
API 網(wǎng)關(guān)作為服務(wù)訪問的統(tǒng)一入口啤月，所有用戶請求都會(huì)過 API 網(wǎng)關(guān)煮仇，很適合用來做認(rèn)證鑒權(quán)這類切面型服務(wù)。網(wǎng)關(guān)可以攔截用戶請求谎仲，獲取請求中附帶的用戶身份信息浙垫，調(diào)用認(rèn)證授權(quán)中心的服務(wù)，對請求者做身份認(rèn)證郑诺，即確認(rèn)當(dāng)前訪問者確實(shí)是其所聲稱的身份夹姥，檢查該用戶是否有訪問該后臺服務(wù)的權(quán)限。
目前主流的認(rèn)證鑒權(quán)方案有 2 種辙诞。
第一種是引入 Redis 做分布式會(huì)話辙售，即用戶登錄成功后，將用戶身份倘要、權(quán)限信息存入 Redis圾亏，以一個(gè)唯一 ID 作為 Key，并設(shè)置信息在 Redis 里的失效時(shí)間封拧。這個(gè)唯一 ID 的 Key 將返回給客戶端志鹃，客戶端可以放入 Cookie，sessionStorage 等處做本地存儲泽西。下次訪問的時(shí)候曹铃，將這個(gè)唯一 ID 放入請求參數(shù)中一起發(fā)送（一般放入 Header）。服務(wù)端通過檢查 Redis 里有無這個(gè) ID 來判斷用戶是否登錄捧杉，獲取用戶身份和權(quán)限信息陕见。客戶端如果長時(shí)間沒有操作味抖，則存儲在 Redis 里會(huì)話信息過期自動(dòng)刪除评甜。客戶端每訪問一次服務(wù)端仔涩，需刷新一次會(huì)話信息的過期時(shí)間忍坷，避免固定過期時(shí)間帶來的低用戶體驗(yàn)。
第二種是 JWT，即 Java Web Token佩研。用戶登錄成功后柑肴，服務(wù)端向客戶端返回的唯一 ID 不再是無意義的字符串，而是包含了用戶身份旬薯、權(quán)限晰骑、失效時(shí)間等信息的加密字符串。并且這個(gè)字符串包含數(shù)字簽名绊序，服務(wù)端可對這個(gè)字符串做數(shù)字簽名驗(yàn)簽硕舆，確保該字符串未經(jīng)篡改和偽造。相比分布式會(huì)話方案政模，JWT 雖省去了 Redis 存儲岗宣，但是每次訪問都要做數(shù)字簽名驗(yàn)證，增加了 CPU 的資源損耗淋样。
