1. 分布式系統(tǒng)認證需求分析

統(tǒng)一認證授權

• 提供獨立的認證服務，提供處理認證授權。無論是不同類型的用戶，還是不同類型的客戶端，均采用一致的認證、授權、繪畫哦按段機制，實現(xiàn)統(tǒng)一認證授權服務。
• 要實現(xiàn)這種統(tǒng)一的認證方式必須可擴展、支持各種認證需求。例如用戶名密碼、短信驗證碼、二維碼、人臉識別等各種認證方式，并可以靈活的切換。

多樣的認證場景

• 例如購物、支付需要有不同的安全級別，也就需要有對應的認證場景。

應用接入認證

• 應提供擴展和開放的能力，提供安全的系統(tǒng)對接機制，并可開放部分api給第三方使用。并且內(nèi)部服務和外部服務第三方服務均采用統(tǒng)一的接入機制。

1. 分布式認證方案

分布式環(huán)境下的認證方案有基于session和基于token兩種方案。

基于session的認證方式：

這種方式依然是由服務端保存統(tǒng)一的用戶信息。只是在分布式環(huán)境下，將session信息同步到各個服務中，并對請求進行負載均衡。

這種方案下，通常由以下幾種做法：

• session復制。在多臺應用服務器之間同步session，并使session保存一致，對外透明。
• session黏貼。當用戶訪問集群中某臺服務器后，強制指定后續(xù)所有請求均落到此服務器上。
• session集中存儲。將session存入分布式緩存中，所有服務器應用實例都統(tǒng)一從分布式緩存中獲取session信息。

總體來講，基于session認證的方式，可以更好的在服務端對會話進行控制，且安全行較高，但是session機制就總體是基于cookie的，客戶端要保存sessionid，這在復炸多樣的客戶端上不能進行有效的使用。另外隨著系統(tǒng)的擴展提高session的復制、奶奶貼、存儲的容錯性。

基于token的認證方式

基于token的認證方式，服務端不在存儲認證數(shù)據(jù)，以維護，擴展性強?？蛻舳丝梢园裻oken存在任意地方，并且可以實現(xiàn)web和app統(tǒng)一認證機制。其缺點也很明顯，客戶端信息容易泄露，token由于包含了大量信息，因此一般數(shù)據(jù)量較大，而每次請求都需要傳遞，因此比較站寬帶。另外token的簽名延簽操作也會帶來額外的負擔。

方案選擇

• 通常情況下，還是會選擇更通用的基于token方式，這樣保證整個系統(tǒng)更靈活的拓展性，并減輕服務端的壓力。
• 在這種方案下，一般會獨立出統(tǒng)一認證服務（UAA）和忘改兩個部分來一起完成認證授權服務。
• 其中，統(tǒng)一認證服務承載介入放認證、登入用戶認證、授權以及令牌管理的職責，完成實際的用戶認證、授權認證。
• 而api網(wǎng)關會作為整個分布式系統(tǒng)的唯一入口，api網(wǎng)關為接入防提供api結合。它本身還可能具有其他輔助職責，如身份認證，監(jiān)控，負載均衡，協(xié)議轉(zhuǎn)換等功能。api網(wǎng)關方式的核心要點是，所有的介入放和消費端都通過統(tǒng)一的網(wǎng)關接入微服務，在網(wǎng)關曾處理所有于業(yè)務無關的功能。整體流程如下圖：

OAuth2.0

概念：

• OAuth（開放授權）是一個開放標準，允許用戶授權第三方應用訪問他們存儲在另外的服務提供者上的信息，而不需要將用戶名和密碼提供給第三方應用或分享他們數(shù)據(jù)的所有內(nèi)容。OAuth2.0是OAuth協(xié)議的延續(xù)版本，但不想后兼容OAuth1.0即完全廢止了OAuth1.0.很多大公司如google、yahoo，等都提供了OAuth認證服務，這些都足以說明OAuth標準逐漸成為開放資源授權的標準。

Spring Security OAuth2.0

環(huán)境介紹

• OAuth是一個開放的授權標準，而Spring Security OAuth2.是對OAuth2協(xié)議的一種實現(xiàn)框架
• OAuth2的服務提供防包含兩個服務，即授權服務（Authorizaton server,也叫認證服務）和資源服務（Resource server）,使用Spring Security OAuth2的時候，可以選擇在同一個應用中來實現(xiàn)這兩個服務，也可以拆分成多個應用來實現(xiàn)同一組授權服務。
• 授權服務（Authorizaton server）應包含對介入段以及登入用戶的合法性進行驗證并頒發(fā)token等功能，對令牌的請求斷點由spring MVC控制器實現(xiàn)，下面是配置一個認證服務必須的endpoints:?

1. AuthorizationEEndpoint 服務于認證請求。默認URL：/oautn/authorize
2. TokenEndpoint服務于訪問令牌的請求。默認URL:/oauth/token
3. OAuth2AuthenticationProcessingFilter 用來對請求給出的身份令牌進行解析健全。

問題：有Spring Security了為什么還要Spring Security OAuth2.0 ，同樣是認證與授權，Spring Security不能實現(xiàn)OAuth2.0 協(xié)議嗎？

OAuth2.0流程示例

• OAuth認證流程，簡單理解，就是允許我們將之前實現(xiàn)的認證和授權的過程交由一個獨立的第三方來進行擔保。而OAuth協(xié)議就是用來頂故意如何讓這個第三方的擔保有效且雙方可信。（以微信掃碼登錄百度為例）

UAA核心三個配置

• ClientDetailServiceConfigurer: 用來配置客戶端詳情（ClientDetailsService）,客戶端詳情信息在這里進行初始化，你能夠把客戶端詳情信息寫死在這里或者是通過數(shù)據(jù)庫來存儲調(diào)取詳情信息。
• AuthorizationServerEndpointsConfigurer: 用來配置令牌（token）的訪問端點和令牌服務（tokenServices）
• AuthorizationServerSecurityConfigurer: 用來配置令牌端點的安全約束

測試：

客戶端模式：client_credentials:

• 這種模式是最方柏霓但是也是最不安全的模式，戴白哦了授權服務器對客戶端的完全互信。因此，這種模式一般可以用在授權服務器對客戶端完全信任的場景，例如內(nèi)部系統(tǒng)或者協(xié)議合作方系統(tǒng)對接。

密碼模式：

• 這種模式用戶會把用戶名和密碼直接泄露給客戶端，代表了資源擁有者和授權服務器對客戶端的絕對互信，相信客戶端不會做壞事。一般適用于內(nèi)部開發(fā)的客戶端的場景。

簡化模式 implicit

示例：

• 這種方案下，一般redirect_uri會配置稱客戶端自己的一個響應地址。這個響應地址接收到授權服務器推送過來的訪問令牌后，就可以將訪問令牌在本地進行保存，然后在需要調(diào)用資源服務時，再拿出來通過資源服務的認證。
• 這種模式下，access_token并不是以get請求參數(shù)的刑師推送的，而是以#fragment方式返回的?
• 這種模式下，oauth三方的數(shù)據(jù)已經(jīng)進行了隔離。這種模式下一般用于沒有服務端的第三方單頁面應用，這樣可以在js里直接響應access_token

授權碼模式 authorization_code

• 返回code

名詞

OAuth2.0

OAuth（開放授權）是一個開放標準，允許用戶授權第三方應用訪問他們存儲在另外的服務提供者上的信息，而不需要將用戶名和密碼提供給第三方應用或分享他們數(shù)據(jù)的所有內(nèi)容。OAuth2.0是OAuth協(xié)議的延續(xù)版本，但不想后兼容OAuth1.0即完全廢止了OAuth1.0.很多大公司如google、yahoo，等都提供了OAuth認證服務，這些都足以說明OAuth標準逐漸成為開放資源授權的標準。

token

令牌，客戶端訪問服務資源的憑證

JWT

json web token (jwt),是為了在網(wǎng)絡環(huán)境間傳遞聲明而執(zhí)行的一種基于JSON的開放標準（RFC_7519）.該token被設計為緊湊且安全的，特別適用于分布式站點的單點登錄（SSO）場景。JWT聲明一般被采用在身份提供者和服務提供者間傳遞的被認證的用戶身份信息，以便于從資源服務器獲取資源，也可以增加一些額外的其他業(yè)務邏輯所必須的聲明信息，以便于從資源服務器獲取資源，也可以增加一些額外的其他業(yè)務邏輯所必須的聲明信息，該token也可直接被用于認證，也可被加密。

Spring Security

Spring Security是一種功能強大且高度可定制的身份驗證和訪問控制框架。它是保護基于sprinv的應用程序的事實上的標準。

Spring Security是一個專注于為Java應用程序提供身份和授權的框架。于所有Spring項目一樣，Spring Security的真正強大之處在于它可以輕松擴展以滿足自定義要求。特征：

• 對身份驗證和授權的全面且擴展的支持。
• 防止會話固定、點擊劫持、跨站點請求仿造等攻擊
• servlet API繼承
• 于spring web mvc的可選集成