之前整理的微服務認證文檔，分享一下

微服務認證解決方案

• • 1.Token認證有兩種方式：OAuth2.0，JWT
  • 2. oAuth2.0授權方式
  • • 2.1授權碼模式：
    • 2.2簡化模式:
    • • 簡化模式詳細介紹
    • 2.3密碼模式：
    • • 密碼模式詳細介紹
    • 2.4客戶端模式：
    • 2.5結論:選擇密碼模式
  • 3.依據用戶名和密碼，獲取token驗證，訪問資源服務器流程
  • 4 .名詞解釋

微服務認證有四種解決方案，分別是：單點登錄SSO方案、分布式會話(Session)方案、客戶端令牌(Token)方案，客戶端和API網關結合；

• 單點登錄方案：是最常見的解決方案，但是每個與用戶交互的服務，都需要通過認證服務器通信，會產生大量的重復認證，和網絡碎片流量。
• 分布式會話方案 ：將用戶信息session 共享存儲；當用戶訪問微服務時，直接從共享存儲中獲取。該解決方案在高可用和擴展方面很好，但是會話信息保存到共享存儲中，要保證數據安全這塊，實現復雜度比較高。
• 客戶端網絡令牌方案:令牌有客戶端生成，并由認證服務器簽名，在令牌中包含足夠的信息，客戶端在請求時會將令牌附件在請求上，從而為為各個微服務提供用戶身份認證。但是如何及時的注銷用戶認證則是一個大問題。
• 客戶端令牌和API網關結合 ：通過微服務架構中實施API網關，將原始的客戶端令牌轉化為內部的令牌，一方面可以有效的隱藏服務，另一方面通過API網關的通一入口可以實現令牌的注銷處理。
• 綜上所述，采用客戶端令牌和API網關，解決了會話信息的安全和及時注銷用戶認證問題。

基于令牌(token)包含幾層含義：

• 令牌是認證用戶信息的集合。
• 令牌包含了足夠的信息，驗證令牌就可以完成用戶的身份的驗證。
• 服務器會通過HTTP頭部中的Authorization獲取令牌信息并進行檢查，并不需要在服務端存儲任何信息。
• 通過服務端驗證令牌檢查機制，可以應用在瀏覽器，和其他第三方應用程序上。
• 支持夸程序的調用。Cookie是不支持跨域訪問，而token不存在這個問題。

1.Token認證有兩種方式：OAuth2.0，JWT

OAuth2.0 授權流程
1)用戶打開客戶端后，客戶端要求用戶給預授權
2)用戶同意給予客戶端授權
3)客戶端使用上一步的授權，向認證服務器申請令牌
4)認證服務器對客戶端進行認證，確定無誤后同意發放令牌
5)客戶端使用令牌，向資源服務服務器申請資源
6)資源服務器確認無誤后，同意向客戶端開發資源

2. oAuth2.0授權方式

客戶端必須得到用戶的授權（authorization grant），才能獲得令牌（access token）。oAuth 2.0 定義了四種授權方式。

• implicit：簡化模式，不推薦使用
• authorization code：授權碼模式
• resource owner password credentials：密碼模式
• client credentials：客戶端模式

2.1授權碼模式：

1.用戶訪問客戶端(應用界面)；
2.客戶端將用戶引導到授權服務器上
3.用戶是否同意客戶端授權；
4.如果同意授權，授權服務器將重定到客戶端事先指定的地址，同時附加上授權碼（token）
5.客戶端收到授權碼后，同時附加上要訪問的頁面，經客戶端后臺服務向授權服務器申請令牌；
6.授權服務驗證授權碼后，向客戶端發送訪問令牌(Access Token)和更新令牌(Refresh Token)并重新制定上步指定的地址；

2.2簡化模式:

指不通過客戶端的后臺服務器來獲取訪問令牌，客戶端一般指的是瀏覽器，客戶端通過腳本語言(一般是javascript)來完成授權服務器申請服務器的操作；

簡化模式詳細介紹

簡化模式適應于純靜態頁面；所謂的純靜態界面應用，也就是應用沒有在服務器代碼執行的權限，(通常把代碼托管在別人服務器上)，只有js代碼的控制權限。
這種場景下，應用沒有持久化的能力。因此按照oAuth2.0的規定，這種應用拿不到Refresh Token的。其授權流程入下圖 。

2.3密碼模式：

密碼模式是指客戶端通過用戶提供的用戶名和密碼信息，直接通過授權信息服務器來獲取授權。這種模式下，用戶把自己用戶名和密碼提供給客戶端，但是客戶端不保存這些信息。
該模式使用，客戶端高度信任的情況下。

該模式授權流程：
1.用戶向客戶提供相應的用戶名和密碼
2.客戶端依據用戶提供的用戶名和密碼，向授權服務器請求令牌
3.授權服務確認后，返回 令牌給客戶端

密碼模式詳細介紹

密碼模式中，用戶向客戶端提供自己的用戶名和密碼。客戶端使用這些信息，向“服務提供商”索要授權(即：向授權服務器索要服務請求令牌)。在這種模式下，用戶必須把用戶名和密碼給客戶端，但是客戶端不存儲密碼。這通常在用戶端對客戶端高度信任的情況下，比如客戶端是操作系統的一部分。

一個典型的例子，同一個企業的不同產品要使用本企業的oAuth2.0體系。有些情況下產品希望能夠定制化，授權界面。由于同一個企業，不需要授權通過授權界面來，詢問用戶授權意向，而只需要認證用戶身份即可。這個時候產品研發定制授權界面，用戶輸入用戶名和密碼，并直接傳遞給授權進行授權即可。

2.4客戶端模式：

指客戶端以自己的名義而不是用戶的名義，向授權服務器進行認證；
客戶端模式詳細介紹
如果信任關系再進一步，或者調用者是一個后端的模塊，沒有用戶界面的時候，可以使用客戶端模式。鑒權服務器直接對客戶端進行身份驗證，驗證通過后，返回 token。

2.5結論:選擇密碼模式

由于，簡化模式整體過程，整個過程在前端界面實現，這里不建議使用，authorization code，雖然是最安全的，最嚴密的，但是網絡交互比較多，由于cem項目是內網實現，相應的API開發的接口不會放在外網，因此建議在密碼模式和客戶端模式中，二者選擇其中一個，建議選擇，密碼模式;
由于cem產品基本上部署打內網環境，建議選擇密碼模式，鑒權服務器直接對客戶端用戶輸入的，用戶名和密碼，進行身份驗證，換取token。

總結 依據產品實際情況出發，選擇適合當前場景的 認證方式；

3.依據用戶名和密碼，獲取token驗證，訪問資源服務器流程

后續補充

4 .名詞解釋

名詞解釋

• 第三方應用程序（Third-party application）： 又稱之為客戶端（client），比如上節中提到的設備（PC、Android、iPhone、TV、Watch），我們會在這些設備中安裝我們自己研發的 APP。又比如我們的產品想要使用 QQ、微信等第三方登錄。對我們的產品來說，QQ、微信登錄是第三方登錄系統。我們又需要第三方登錄系統的資源（頭像、昵稱等）。對于 QQ、微信等系統我們又是第三方應用程序。
• HTTP 服務提供商（HTTP service）： 我們的云筆記產品以及 QQ、微信等都可以稱之為“服務提供商”。
• 資源所有者（Resource Owner）： 又稱之為用戶（user）。
• 用戶代理（User Agent）： 比如瀏覽器，代替用戶去訪問這些資源。
• 認證服務器（Authorization server）： 即服務提供商專門用來處理認證的服務器，簡單點說就是登錄功能（驗證用戶的賬號密碼是否正確以及分配相應的權限）
• 資源服務器（Resource server）： 即服務提供商存放用戶生成的資源的服務器。它與認證服務器，可以是同一臺服務器，也可以是不同的服務器。簡單點說就是資源的訪問入口，比如上節中提到的“云筆記服務”和“云相冊服務”都可以稱之為資源服務器。

總結

以上是生活随笔為你收集整理的微服务认证解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。