|
OAuth2是一個(gè)授權(quán)（Authorization）協(xié)議。我們要和Spring Security的認(rèn)證（Authentication）區(qū)別開來(lái)，認(rèn)證（Authentication）證明的你是不是這個(gè)人，而授權(quán)（Authorization）則是證明這個(gè)人有沒有訪問這個(gè)資源（Resource）的權(quán)限。  +--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
先來(lái)解釋一下上圖的名詞： Resource Owner：資源所有者，即用戶 Client：客戶端應(yīng)用程序（Application） Authorization Server：授權(quán)服務(wù)器 Resource Server：資源服務(wù)器
再來(lái)解釋一下上圖的大致流程： （A） 用戶連接客戶端應(yīng)用程序以后，客戶端應(yīng)用程序要求用戶給予授權(quán) （B） 用戶同意給予客戶端應(yīng)用程序授權(quán) （C） 客戶端應(yīng)用程序使用上一步獲得的授權(quán)（Grant），向授權(quán)服務(wù)器申請(qǐng)令牌 （D） 授權(quán)服務(wù)器對(duì)客戶端應(yīng)用程序的授權(quán)（Grant）進(jìn)行驗(yàn)證后，確認(rèn)無(wú)誤，發(fā)放令牌 （E） 客戶端應(yīng)用程序使用令牌，向資源服務(wù)器申請(qǐng)獲取資源 （F） 資源服務(wù)器確認(rèn)令牌無(wú)誤，同意向客戶端應(yīng)用程序開放資源
從上面的流程可以看出，如何獲取授權(quán)（Grant）才是關(guān)鍵。在OAuth2中有4種授權(quán)類型： 1. Authorization Code（授權(quán)碼模式）：功能最完整、流程最嚴(yán)密的授權(quán)模式。通過第三方應(yīng)用程序服務(wù)器與認(rèn)證服務(wù)器進(jìn)行互動(dòng)。廣泛用于各種第三方認(rèn)證。 2. Implicit（簡(jiǎn)化模式）：不通過第三方應(yīng)用程序服務(wù)器，直接在瀏覽器中向認(rèn)證服務(wù)器申請(qǐng)令牌，更加適用于移動(dòng)端的App及沒有服務(wù)器端的第三方單頁(yè)面應(yīng)用。 3. Resource Owner Password（密碼模式）：用戶向客戶端服務(wù)器提供自己的用戶名和密碼，用戶對(duì)客戶端高度信任的情況下使用，比如公司、組織的內(nèi)部系統(tǒng)，SSO。 4. Client Credentials（客戶端模式）：客戶端服務(wù)器以自己的名義，而不是以用戶的名義，向認(rèn)證服務(wù)器進(jìn)行認(rèn)證。 下面主要講最常用的（1）和（3）。此外，還有一個(gè)模式叫Refresh Token，也會(huì)在下面介紹。
Authorization Code（授權(quán)碼模式） +----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
Note: The lines illustrating steps (A), (B), and (C) are broken into
two parts as they pass through the user-agent.
它的步驟如下： （A） 用戶（Resource Owner）通過用戶代理（User-Agent）訪問客戶端（Client），客戶端索要授權(quán)，并將用戶導(dǎo)向認(rèn)證服務(wù)器（Authorization Server）。 （B） 用戶選擇是否給予客戶端授權(quán)。 （C） 假設(shè)用戶給予授權(quán)，認(rèn)證服務(wù)器將用戶導(dǎo)向客戶端事先指定的"重定向URI"（redirection URI），同時(shí)附上一個(gè)授權(quán)碼。 （D） 客戶端收到授權(quán)碼，附上早先的"重定向URI"，向認(rèn)證服務(wù)器申請(qǐng)令牌。這一步是在客戶端的后臺(tái)的服務(wù)器上完成的，對(duì)用戶不可見。 （E） 認(rèn)證服務(wù)器核對(duì)了授權(quán)碼和重定向URI，確認(rèn)無(wú)誤后，向客戶端發(fā)送訪問令牌（access token）和更新令牌（refresh token）。這一步也對(duì)用戶不可見。
Resource Owner Password（密碼模式） +----------+
| Resource |
| Owner |
| |
+----------+
v
| Resource Owner
(A) Password Credentials
|
v
+---------+ +---------------+
| |>--(B)---- Resource Owner ------->| |
| | Password Credentials | Authorization |
| Client | | Server |
| |<--(C)---- Access Token ---------<| |
| | (w/ Optional Refresh Token) | |
+---------+ +---------------+
Figure 5: Resource Owner Password Credentials Flow
它的步驟如下： （A） 用戶（Resource Owner）向客戶端（Client）提供用戶名和密碼。 （B） 客戶端將用戶名和密碼發(fā)給認(rèn)證服務(wù)器（Authorization Server），向后者請(qǐng)求令牌。 （C） 認(rèn)證服務(wù)器確認(rèn)無(wú)誤后，向客戶端提供訪問令牌。
令牌刷新（refresh token） +--------+ +---------------+ | |--(A)------- Authorization Grant --------->| | | | | | | |<-(B)----------- Access Token -------------| | | | & Refresh Token | | | | | | | | +----------+ | | | |--(C)---- Access Token ---->| | | | | | | | | | | |<-(D)- Protected Resource --| Resource | | Authorization | | Client | | Server | | Server | | |--(E)---- Access Token ---->| | | | | | | | | | | |<-(F)- Invalid Token Error -| | | | | | +----------+ | | | | | | | |--(G)----------- Refresh Token ----------->| | | | | | | |<-(H)----------- Access Token -------------| | +--------+ & Optional Refresh Token +---------------+ 具體流程不再分析，我們已知，當(dāng)我們申請(qǐng)token后，Authorization Server不僅給了我們Access Token，還有Refresh Token。當(dāng)Access Token過期后，我們用Refresh Token訪問/refresh端點(diǎn)就可以拿到新的Access Token了。
本節(jié)只講概念，在接下來(lái)的幾節(jié)中會(huì)搭建一組含有Client Application, Authorization Server, Resource Server的微服務(wù)群，并使用Eureka和Config組件管理。 |
|
|
來(lái)自： 米老鼠的世界 > 《Java_Spring》
