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