用什么做網(wǎng)站最簡單百度招商加盟
一、簡介
? ? ?OAuth 是一個開放標準，該標準允許用戶讓第三方應(yīng)用訪問該用戶在某一網(wǎng)站上存儲的私密資源(如頭像、照片、視頻等)，并且在這個過程中無須將用戶名和密碼提供給第三方應(yīng)用。通過令牌(token)可以實現(xiàn)這一功能，每一個令牌授權(quán)一個特定的網(wǎng)站在特定的時段內(nèi)允許可特定的資源。0Auth讓用戶可以授權(quán)第三方網(wǎng)站靈活訪問它們存儲在另外一些資源服務(wù)器上的特定信息，而非所有內(nèi)容。對于用戶而言，我們在互聯(lián)網(wǎng)應(yīng)用中最常見的 OAuth應(yīng)用就是各種第三方登錄，例如QQ授權(quán)登錄、微信授權(quán)登錄、微博授權(quán)登錄、GitHub 授權(quán)登錄等。
例如用戶想登錄 Ruby China，傳統(tǒng)方式是使用用戶名密碼但是這樣并不安全，因為網(wǎng)站會存儲你的用戶名密碼，這樣可能會導致密碼泄露。這種授權(quán)方式安全隱患很大，如果使用 0Auth 協(xié)議就能很好地解決這一問題。
???注意：OAuth2 是0Auth 協(xié)議的下一版本，但不兼容 Auth 1.0。 OAuth2 關(guān)注客戶端開發(fā)者的簡易性，同時為 web 應(yīng)用、桌面應(yīng)用、移動設(shè)備IoT 設(shè)備提供專門的認證流程。
二、OAuth2 四種授權(quán)模式
? ? 0Auth2 協(xié)議一共支持四種不同的授權(quán)模式，?無論哪種授權(quán)模式，其授權(quán)流程都是相似的，只不過在個別步驟上有一些差異而已；
- 授權(quán)碼模式:常見的第三方平臺登錄功能基本都是使用這種模式；
- 簡化橫式:簡化模式是不需要第三方服務(wù)端參與，直接在瀏覽器中向授權(quán)服務(wù)器申請令牌 (token)，如果網(wǎng)站是純靜態(tài)頁面，則可以采用這種方式。
- 密碼模式:密碼模式是用戶把用戶名/密碼直接告訴客戶端，客戶端使用這些信息后授權(quán)服務(wù)器申請令牌(token)。這需要用戶對客戶端高度信任，例如3客戶端應(yīng)用和服務(wù)提供商就是同一家公司。
- 客戶端模式:客戶端模式是指客戶端使用自己的名義而不是用戶的名義向服務(wù)提估者申請授權(quán)。嚴格來說，客戶諾模式并不能算作0Auth協(xié)議解決問題的種解決方案，但是對于開發(fā)者而言，在一些為移動端提供的授權(quán)服務(wù)器上使用這種模式還是非常方便的。
-(A) 用戶打開客戶端以后，客戶端要求用戶給予授權(quán)。
-(B) 用戶同意給予客戶端授權(quán)。
-(C) 客戶端使用上一步獲得的授權(quán)，向認證服務(wù)器申請令牌。
-(D) 認證服務(wù)器對客戶端進行認證以后，確認無誤，同意發(fā)放令牌。
-(E) 客戶端使用令牌，向資源服務(wù)器申請獲取資源。
-(F)? 資源服務(wù)器確認令牌無誤，同意向客戶端開放資源。
從上圖中我們可以看出六個步驟之中，B是關(guān)鍵，即用戶怎樣才能給于客戶端授權(quán)。同時會發(fā)現(xiàn) OAuth2 中包含四種不同的角色:
。 client : 第三方應(yīng)用。
。 Resource 0wner: 資源所有者。
。 Authorization Server: 授權(quán)服務(wù)器。
。 Resource Server:? 資源服務(wù)器。
2.1 授權(quán)碼模式
? ? 授權(quán)碼模式(Authorization?code) 是功能最完整、流程最嚴密、最安全并且使用最廣泛的一種0Auth2 授權(quán)模式。同時也是最復(fù)雜的一種授權(quán)模式，它的特點就是通過客戶端的后臺服務(wù)器，與服務(wù)提供商的認證服務(wù)器進行互動；
Third-party application:第三方應(yīng)用程序，簡稱"客戶端”(client);
。Resource 0wner:資源所有者，簡稱"用戶” (user) ;
。User Aqent:用戶代理，是指瀏覽器;
。Authorization Server:認證服務(wù)器，即服務(wù)端專門用來處理認證的服務(wù)器;
。Resource Server;資源服務(wù)器，即服務(wù)端存放用戶生成的資源的服務(wù)器。它與認證服務(wù)器，可以是同一臺服務(wù)器，也可以是不同的服務(wù)器
流程圖連接：RFC 6749 - The OAuth 2.0 Authorization Framework
具體流程如下:
(A) 用戶訪問第三方應(yīng)用，第三方應(yīng)用通過瀏覽器導向認證服務(wù)器。
(B) 用戶選擇是否給予客戶端授權(quán)。
(C) 假設(shè)用戶給予授權(quán)，認證服務(wù)器將用戶導向客戶端事先指定的"重定向URI”(redirection URI)，同時附上一個授權(quán)碼。
(D) 客戶端收到授權(quán)碼，附上早先的"重定向URI"，向認證服務(wù)器申請令牌。這一步是在客戶端的后臺的服務(wù)器上完成的，對用戶不可見。
(E) 認證服務(wù)器核對了授權(quán)碼和重定向URI，確認無誤后，向客戶端發(fā)送訪問令牌 (access token)和更新牌(refresh token)
2.1.1 核心參數(shù)
https://wx.com/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=http://www.baidu.com&scope=read
2.1.2 參數(shù)詳解
| client_id | 授權(quán)服務(wù)器注冊應(yīng)用后的唯一標識 |
| response_type | 必須 固定值 在授權(quán)碼中必須為 code |
| redirect_uri | 必須 通過客戶端注冊的重定向URL |
| scope | 必須 令牌可以訪問資源權(quán)限 read 只讀? ?all 讀寫 |
| state | 可選 存在原樣返回客戶端 用來防止 CSRF跨站攻擊 |
2.2? 簡化模式
? ? 簡化模式(simple?grant type) 不通過第三方應(yīng)用程序的服務(wù)器，直接在測覽器中向認證服務(wù)器申請令牌，跳過了"授權(quán)碼"這個步，因此得名。所有步驟在瀏覽器中完成，令牌對訪問者是可見的，且客戶端不需要認證。
其具體的授權(quán)流程如圖所示：
（A)? ?第三方應(yīng)用將用戶導向認證服務(wù)器
? (B)? ? 用戶決定是否給于客戶端授權(quán)。.
? (C)? ?假設(shè)用戶給予授權(quán)，認證服務(wù)器將用戶導向客戶端指定的"重定向URI"，并在URI的Hash部分包含了訪問令牌。#token.
? (D)? ?瀏覽器向資源服務(wù)器發(fā)出請求，其中不包括上一步收到的Hash值。.
? (E)? ?資源服務(wù)器返回一個網(wǎng)頁，其中包含的代碼可以獲取Hash值中的令牌。
? (F)? ?瀏覽器執(zhí)行上一步獲得的腳本，提取出令牌。
? (G)? ?瀏覽器將令牌發(fā)給客戶端。
2.2.1? 核心參數(shù)
https://wx.com/oauth/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=http://wmw.baidu.com&scope=read
2.2.2? 參數(shù)詳解
| ? ? ? ? ? ? ? ? 字段 | ? ? ? ? ? ? ? ? ? ? 描述 |
|---|---|
| client_id | 授權(quán)服務(wù)器注冊應(yīng)用后的唯一標識 |
| response_type | 必須 固定值 在授權(quán)碼中必須為token |
| redirect_uri | 必須 通過客戶端注冊的重定向URL |
| scope | 必須 令牌可以訪問資源權(quán)限 read 只讀? ?all 讀寫 |
| state | 可選 存在原樣返回客戶端 用來防止 CSRF跨站攻擊 |
2.3?密碼模式
密碼模式(Resource 0wner Password Credentias grant)中，用戶向客戶端提供自己的用戶各和密碼?？蛻舳耸褂眠@些信息，向“服務(wù)商提供兩"索要授權(quán)。在這種模式中，用戶必須把自己的密碼給客戶端，但是客戶端不得儲存密碼。這通常用在用戶對客戶端高度信任的情下，比如客戶端是操作系統(tǒng)的一部分，或者由一個相同公司出品。而認證服務(wù)圖只有在其他授權(quán)模式無法執(zhí)行的情況下，才能考慮使用這種模式。
其具體的授權(quán)流程如圖所示
具體步驟如下:
(A) 用戶向客戶端提供用戶名和密碼。
(B) 客戶端將用戶名和密碼發(fā)給認證服務(wù)器，向后者請求令牌。
(C) 認證服務(wù)器確認無誤后，向客戶端提供訪間令牌。
2.3.1 核心參數(shù)
https://wx.com/token?grant_type=password&username-USERNAME&password=PASSWORD&client_id=CLIENT_ID
2.4?客戶端模式
客戶端模式(Client Credentials Grant)?指客戶端以自己的名義，而不是以用戶的名義，向"服務(wù)提供商"進行認證。嚴格地說，客戶端模式并不屬于0Auth框架所要解決的問題。在這種模式中，用戶直接向客戶端注冊，客戶端以自己的名義要求”服務(wù)提供商“提供服務(wù)，其實不存在授權(quán)問題。
授權(quán)流程圖如下
具體步驟如下:
(A) 客戶端向認證服務(wù)器進行身份認證，并要求一個訪問令牌。
(B) 認證服務(wù)器確認無誤后，向客戶端提供訪問令牌。
2.4.1 核心參數(shù)
? ? ?https://wx.com/token?grant_type=client_credentials&client_secret=CLIENT_SECRET&client_id=CLIENT_ID
三、OAuth2 標準接口
。 /oauth/authorize:? 授權(quán)端點
。 /oauth/token: 獲取令牌端點
。/oauth/confirm_access: 用戶確認授權(quán)提交端點
。/oauth/error: 授權(quán)服務(wù)錯誤信息端點
。/oauth/check_token:? 用于資源服務(wù)訪問的令牌解析端點
。/oauth/token_key: 提供公有密匙的端點，如果使用JWT令牌的話
四、案例實踐
使用 gitee 授權(quán)登錄，登錄成功后訪問 hello接口，獲取授權(quán)后的信息
4.1?OAuth2結(jié)合Gitee授權(quán)案例
打開引用設(shè)置：https://gitee.com/oauth/applications
1、進入第三方應(yīng)用
2、創(chuàng)建應(yīng)用，填寫回調(diào)的地址以及主頁地址
4.2 后端配置
@Configuration
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {@Overrideprotected void configure(HttpSecurity http) throws Exception {http.authorizeRequests().anyRequest().authenticated().and().oauth2Login();// 使用oauth2 認證，配置從配置文件中讀取}
}導入依賴
--所需的依賴<!-- oauth2 客戶端 --><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-oauth2-client</artifactId></dependency>?
配置 yml 文件將gitee 加入provider 中
? ?如果不加的話，啟動會報 provider Id not found 相當于要明確指出來
spring:security:oauth2:client:registration:gitee:provider: giteeclient-id: 83f45xxxf29198ff68ada42f8client-secret: 61e7fe7502a0fd162exx429542f739c9ba6322
# 重定向的url地址，這個地址為默認的redirect-uri: http://localhost:8082/login/oauth2/code/giteeauthorization-grant-type: "authorization_code"client-name: gitee#不配置這個會報 gitee找不到provider:gitee:authorization-uri: https://gitee.com/oauth/authorizetoken-uri: https://gitee.com/oauth/tokenuser-info-uri: https://gitee.com/api/v5/useruser-name-attribute: "name"
4.3 測試controller
? 用于授權(quán)成功后，獲取oauth2的用戶信息
@RestController
public class HelloController {/*** 獲取認證后的用戶信息* @return*/@RequestMapping("hello")public DefaultOAuth2User hello() {System.out.println("oauth2用戶信息獲取");Authentication authentication = SecurityContextHolder.getContext().getAuthentication();return (DefaultOAuth2User)authentication.getPrincipal();}}4.4 授權(quán)效果
? ?當我們啟動項目后，訪問 8082接口，自動給我們定向到 gitee授權(quán)頁面，我們同意后，就會跳到我們配置的主頁面了；
4.5 同時開啟表單登錄
當我們啟動項目后，會自動進入到授權(quán)頁面了，但是有時候我們需要在登錄頁面加上 gitee的入口，當用戶點擊后，我們才開始進行授權(quán)的操作，這個該怎么做呢，其實我們開啟我們的表單認證就好了；
http.authorizeRequests().anyRequest().authenticated().and().formLogin()//開啟表單登錄.and().oauth2Login();// 使用oauth2 認證，配置從配置文件中讀取
五、授權(quán)過濾器源碼查看
? ?我們肯定在疑問，我們項目里面并沒有/login/oauth2/code 這個接口，為什么能訪問呢，我們自己加上了 gitee如何就能收到對應(yīng)的授權(quán)呢；
接下來我們來看???OAuth2LoginAuthenticationFilter 源碼
5.1 源碼入口
org.springframework.security.config.annotation.web.builders.HttpSecurity#oauth2Login()
? ? ? org.springframework.security.config.annotation.web.configurers.oauth2.client.OAuth2LoginConfigurer
? ? org.springframework.security.oauth2.client.web.OAuth2LoginAuthenticationFilter
? ?DEFAULT_FILTER_PROCESSES_URI = "/login/oauth2/code/*";
5.2? attemptAuthentication() 方法
?attemptAuthentication(HttpServletRequest request, HttpServletResponse response)
org.springframework.security.authentication.AuthenticationManager#authenticate?這一步就是請求 gitee的認證服務(wù)器
5.3 OAuth2AuthenticationToken
? ?當我們通過Oauth2認證成功后，系統(tǒng)會返回一個OAuth2AuthenticationToken對象，同事會將用戶信息包裝一個 OAuth2User ，對應(yīng)的實現(xiàn)為DefaultOAuth2User
六、spring security OAuth2 雜談
該文獻參考? 嗶站? 編程不良人 ，有需求可以關(guān)注他
? ? ?Spring Security 對 0Ath2 提供了很好的支持，這使得我們在 Spring Security中使用 0Auth2 非常地方便。然而由于歷史原因，SoringSeaurity對0Auth2的支持比較混亂，這里簡單梳理一下。
大約十年前，Spring 引入了一個社區(qū)驅(qū)動的開源項目 Spring Security 0Auth，并將其納入 Spring 項目組合中到今天為止，這個項目己經(jīng)發(fā)展成為一個成熟的項目，可以支持大部分0Auth 規(guī)范，包括資源服務(wù)器、 客戶端和授權(quán)服務(wù)器等。
然而早期的項目存在一些問題，例如:
0Auth 是在早期完成的，開發(fā)者無法預(yù)料未來的變化以及這些代碼到底要被怎么使用.這導致很多 Spring 項目提供了自己的 0Auth 支持，也就帶來了 0Auth 支持的碎片化。最早的0Auth項目同時支特 0Auth1. 和 0Auth2.0，而現(xiàn)在0Autb1 早已經(jīng)不再使用可以放棄了。
現(xiàn)在我們有更多的庫可以選擇，可以在這些庫的基礎(chǔ)上去開發(fā)，以便更好地支持JWT等新技術(shù)?；谝陨线@些原因，官方?jīng)Q定重寫 Spring ecurity 0Auth, 以便更好地協(xié)調(diào) Spring 和Auth，并簡化代碼庫，使Spring 的 0Auth 支持更加靈活。然而，在重寫的過程中，發(fā)生了不少波折。
2018年1月30日，Sprng 官方發(fā)了一個通知，表示要逐漸停止現(xiàn)有的 0Ath2支持，然后在 Spring Security 5中構(gòu)建下一代 Auth2.0 支持。這么做的原因是因為當時 0Auth2 的落地方案比較混亂，在 Spring Security 0Auth、Spring cloud Security、Spring Boot 1.5.x 以及當時最新的Spring Security 5.x 中都提供了對 Auth2 的實現(xiàn)。以至于當開發(fā)者需要使用 0Auth2 時，不得不問，到底選哪一個依賴合適呢?所以Spring 官方?jīng)Q定有必要將 Auth2.0 的支持統(tǒng)一到一個項目中，以便為用戶提供明確的選擇，并避免何潛在的混亂，同時 OAuth20的開發(fā)文檔也要重新編寫，以方便開發(fā)人員學習。所有的決定將在 pring Security 5 中開始，構(gòu)建下一代 Ath2的支持。從那個時候起，Spring Security0Auth項目就正式處于維護模式。官方將提供至少一年的錯識/安全修復(fù)程序，并且會考慮添加次要功能，但不會添加主要功能。同時將 Spring Security 0Auth中的所有功能重構(gòu)到 Spring Security 5x中
到了2019年11月14日，Spring 官方又發(fā)布-個通知，這次的通知首先表示 Spring Security 0Auth 在往 Spring Security 5.x 的過程非常順利，大都分遷程工作已經(jīng)完成了，剩下的將在5.3 版本中完成遷移，在遷移的過程中還添加了許多新功能。包括對 openId ?Connect1.0 的支持。同時還宣布將不再支持授權(quán)服務(wù)器，不支持的原因有兩個:
1、在2019年，已經(jīng)有大量的商業(yè)和開源投權(quán)服務(wù)器可用，
2、授權(quán)服務(wù)器是使用一個庫來構(gòu)建產(chǎn)品，而 Spring Security 作為框架，并不適合做這件事情
一石激起千層浪，許多開發(fā)者表示對此難以接受。這件事也在Spring 社區(qū)引發(fā)了激烈的討論，好在 Spring 官方愿意傾聽來自社區(qū)的聲音。
到了2020年4月15日，Spring 官方宣布啟動 Spring Authorization server 項目。這是-個由 Spring ecurity 團隊領(lǐng)導的社區(qū)驅(qū)動的項目致力于向 Spring 社區(qū)提供 Authorization Server支持，也就是說，Spring 又重新支持授權(quán)服務(wù)器了。2020年8月21日，Spring Authorization Server 0.0.1正式發(fā)布!
這就是 Auth2在Spring 家族中的發(fā)展歷程了。在后面章節(jié)中，客戶端和資源服務(wù)器都將采用最新的方式來構(gòu)建，授權(quán)服務(wù)器依然采用舊的方式來構(gòu)建因為目前的 Spring Authorization Server 0.0.1功能較少且 BUG 較多。