OAuth2和Spring Security（請(qǐng)選擇以下列出的主題并嘗試，越好越好）
1.了解OAuth2概念和支持的授權(quán)類(lèi)型流程。 并研究如何根據(jù)客戶(hù)類(lèi)型以及是否涉及用戶(hù)選擇授予類(lèi)型。 （推薦的）
參考學(xué)習(xí)文章：理解OAuth 2.0-阮一峰
專(zhuān)有名詞
(1） Third-party application：第三方應(yīng)用程序，本文中又稱(chēng)"客戶(hù)端"（client），即上一節(jié)例子中的"云沖印"。
（2）HTTP service：HTTP服務(wù)提供商，本文中簡(jiǎn)稱(chēng)"服務(wù)提供商"，即上一節(jié)例子中的Google。
（3）Resource Owner：資源所有者，本文中又稱(chēng)"用戶(hù)"（user）。
（4）User Agent：用戶(hù)代理，本文中就是指瀏覽器。
（5）Authorization server：認(rèn)證服務(wù)器，即服務(wù)提供商專(zhuān)門(mén)用來(lái)處理認(rèn)證的服務(wù)器。
（6）Resource server：資源服務(wù)器，即服務(wù)提供商存放用戶(hù)生成的資源的服務(wù)器。它與認(rèn)證服務(wù)器，可以是同一臺(tái)服務(wù)器，也可以是不同的服務(wù)器。
OAuth的作用就是讓"客戶(hù)端"安全可控地獲取"用戶(hù)"的授權(quán)，與"服務(wù)商提供商"進(jìn)行互動(dòng)。
OAuth在"客戶(hù)端"與"服務(wù)提供商"之間，設(shè)置了一個(gè)授權(quán)層（authorization layer）。"客戶(hù)端"不能直接登錄"服務(wù)提供商"，只能登錄授權(quán)層，以此將用戶(hù)與客戶(hù)端區(qū)分開(kāi)來(lái)。"客戶(hù)端"登錄授權(quán)層所用的令牌（token），與用戶(hù)的密碼不同。用戶(hù)可以在登錄的時(shí)候，指定授權(quán)層令牌的權(quán)限范圍和有效期。
"客戶(hù)端"登錄授權(quán)層以后，"服務(wù)提供商"根據(jù)令牌的權(quán)限范圍和有效期，向"客戶(hù)端"開(kāi)放用戶(hù)儲(chǔ)存的資料。
（A）用戶(hù)打開(kāi)客戶(hù)端以后，客戶(hù)端要求用戶(hù)給予授權(quán)。
（B）用戶(hù)同意給予客戶(hù)端授權(quán)。
（C）客戶(hù)端使用上一步獲得的授權(quán)，向認(rèn)證服務(wù)器申請(qǐng)令牌。
（D）認(rèn)證服務(wù)器對(duì)客戶(hù)端進(jìn)行認(rèn)證以后，確認(rèn)無(wú)誤，同意發(fā)放令牌。
（E）客戶(hù)端使用令牌，向資源服務(wù)器申請(qǐng)獲取資源。
（F）資源服務(wù)器確認(rèn)令牌無(wú)誤，同意向客戶(hù)端開(kāi)放資源
第三方登錄原理，流程，url 處理走向
1. A 網(wǎng)站讓用戶(hù)跳轉(zhuǎn)到 GitHub。
從頁(yè)面的link 去登錄通過(guò)github：
url:https://github.com/login/oauth/authorize?client_id=7e015d8ce32370079895&redirect_uri=http://localhost:8080/oauth/redirect
client_id告訴 GitHub 誰(shuí)在請(qǐng)求，redirect_uri是稍后跳轉(zhuǎn)回來(lái)的網(wǎng)址。
參數(shù)：client_id,redirect_uri
2.GitHub 要求用戶(hù)登錄，然后詢(xún)問(wèn)"A 網(wǎng)站要求獲得 xx 權(quán)限，你是否同意？"
同意：GitHub 就會(huì)跳轉(zhuǎn)到redirect_uri指定的跳轉(zhuǎn)網(wǎng)址
3. 用戶(hù)同意，GitHub 就會(huì)重定向回 A 網(wǎng)站，同時(shí)發(fā)回一個(gè)授權(quán)碼。
url: http://localhost:8080/oauth/redirect?code=859310e7cecc9196f4af
4. A 網(wǎng)站使用授權(quán)碼，向 GitHub 請(qǐng)求令牌。
GitHub 返回令牌.
https://github.com/login/oauth/access_token?client_id=123456&client_secret=saaddfsddfs&code=859310e7cecc9196f4af
method:post
headers:{
accept:'application/json'
}
Response:{
access_token: fsljfjlsdfsdlslfa
}
5. A 網(wǎng)站使用令牌，向 GitHub 請(qǐng)求用戶(hù)數(shù)據(jù)。
url:https://api.github.com/user
headers:{
accept:'application/json',
Authorization: 'token fsljfjlsdfsdlslfa'
}
OAuth四種類(lèi)型：
OAuth 2.0 規(guī)定了四種獲得令牌的流程
-
授權(quán)碼（authorization-code
這種方式是最常用的流程，安全性也最高，它適用于那些有后端的 Web 應(yīng)用。授權(quán)碼通過(guò)前端傳送，令牌則是儲(chǔ)存在后端，而且所有與資源服務(wù)器的通信都在后端完成。這樣的前后端分離，可以避免令牌泄漏。
https://b.com/oauth/authorize?
response_type=code&
client_id=CLIENT_ID&
redirect_uri=CALLBACK_URL&
scope=read
image.png
https://a.com/callback?code=AUTHORIZATION_CODE
image.png
https://b.com/oauth/token?
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
grant_type=authorization_code&
code=AUTHORIZATION_CODE&
redirect_uri=CALLBACK_URL
image.png
{
"access_token":"ACCESS_TOKEN",
"token_type":"bearer",
"expires_in":2592000,
"refresh_token":"REFRESH_TOKEN",
"scope":"read",
"uid":100101,
"info":{...}
}
-
隱藏式（implicit)
有些 Web 應(yīng)用是純前端應(yīng)用，沒(méi)有后端。這時(shí)就不能用上面的方式了，必須將令牌儲(chǔ)存在前端。RFC 6749 就規(guī)定了第二種方式，允許直接向前端頒發(fā)令牌。這種方式?jīng)]有授權(quán)碼這個(gè)中間步驟，所以稱(chēng)為（授權(quán)碼）"隱藏式"（implicit）。
https://b.com/oauth/authorize?
response_type=token&
client_id=CLIENT_ID&
redirect_uri=CALLBACK_URL&
scope=read
上面 URL 中，response_type參數(shù)為token，表示要求直接返回令牌。
https://a.com/callback#token=ACCESS_TOKEN
注意，令牌的位置是 URL 錨點(diǎn)（fragment），而不是查詢(xún)字符串（querystring），這是因?yàn)?OAuth 2.0 允許跳轉(zhuǎn)網(wǎng)址是 HTTP 協(xié)議，因此存在"中間人攻擊"的風(fēng)險(xiǎn)，而瀏覽器跳轉(zhuǎn)時(shí)，錨點(diǎn)不會(huì)發(fā)到服務(wù)器，就減少了泄漏令牌的風(fēng)險(xiǎn)。
這種方式把令牌直接傳給前端，是很不安全的。因此，只能用于一些安全要求不高的場(chǎng)景，并且令牌的有效期必須非常短，通常就是會(huì)話期間（session）有效，瀏覽器關(guān)掉，令牌就失效了。
- 密碼式（password）：
- 第一步，A 網(wǎng)站要求用戶(hù)提供 B 網(wǎng)站的用戶(hù)名和密碼。拿到以后，A 就直接向 B 請(qǐng)求令牌。
https://oauth.b.com/token?
grant_type=password&
username=USERNAME&
password=PASSWORD&
client_id=CLIENT_ID
上面 URL 中，grant_type參數(shù)是授權(quán)方式，這里的password表示"密碼式"，username和password是 B 的用戶(hù)名和密碼。
- 第二步，B 網(wǎng)站驗(yàn)證身份通過(guò)后，直接給出令牌。注意，這時(shí)不需要跳轉(zhuǎn)，而是把令牌放在 JSON 數(shù)據(jù)里面，作為 HTTP 回應(yīng)，A 因此拿到令牌
用戶(hù)給出自己的用戶(hù)名/密碼，顯然風(fēng)險(xiǎn)很大，因此只適用于其他授權(quán)方式都無(wú)法采用的情況，
- 客戶(hù)端憑證（client credentials）
最后一種方式是憑證式（client credentials），適用于沒(méi)有前端的命令行應(yīng)用，即在命令行下請(qǐng)求令牌。
- 第一步，A 應(yīng)用在命令行向 B 發(fā)出請(qǐng)求。
https://oauth.b.com/token?
grant_type=client_credentials&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET
- 第二步，B 網(wǎng)站驗(yàn)證通過(guò)以后，直接返回令牌。
這種方式給出的令牌，是針對(duì)第三方應(yīng)用的，而不是針對(duì)用戶(hù)的，即有可能多個(gè)用戶(hù)共享同一個(gè)令牌。
更新令牌
令牌的有效期到了，如果讓用戶(hù)重新走一遍上面的流程，再申請(qǐng)一個(gè)新的令牌，很可能體驗(yàn)不好，而且也沒(méi)有必要。OAuth 2.0 允許用戶(hù)自動(dòng)更新令牌。
具體方法是，B 網(wǎng)站頒發(fā)令牌的時(shí)候，一次性頒發(fā)兩個(gè)令牌，一個(gè)用于獲取數(shù)據(jù)，另一個(gè)用于獲取新的令牌（refresh token 字段）。令牌到期前，用戶(hù)使用 refresh token 發(fā)一個(gè)請(qǐng)求，去更新令牌。
https://b.com/oauth/token?
grant_type=refresh_token&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
refresh_token=REFRESH_TOKEN
上面 URL 中，grant_type參數(shù)為refresh_token表示要求更新令牌，client_id參數(shù)和client_secret參數(shù)用于確認(rèn)身份，refresh_token參數(shù)就是用于更新令牌的令牌。
B 網(wǎng)站驗(yàn)證通過(guò)以后，就會(huì)頒發(fā)新的令牌。
2.了解為什么不再建議授予類(lèi)型“隱式代碼”。 （推薦的）
3.使用openid（例如GitHub）或Spring安全授權(quán)服務(wù)器構(gòu)建Spring安全演示（包括客戶(hù)端和資源服務(wù)器）。 （推薦的）
4.使用啟用了Spring安全性的資源服務(wù)器構(gòu)建Vue.js客戶(hù)端（僅基于瀏覽器）（推薦）
5.構(gòu)建包括客戶(hù)端，網(wǎng)關(guān)，資源服務(wù)器在內(nèi)的Spring安全演示，并在網(wǎng)關(guān)中進(jìn)行身份驗(yàn)證（可選）。
6.用UAA服務(wù)器構(gòu)建Spring安全演示（包括客戶(hù)端和資源服務(wù)器）。 您可以參考：
?PCF uaa示例應(yīng)用程序：https://github.com/pivotal-cf/identity-sample-apps
?UAA服務(wù)器https://docs.run.pivotal.io/concepts/architecture/uaa.html（可選）
