場景
小明同學下載了一款遊戲，王者榮耀。通過使用三方授權的方式登錄，在微信內點擊同意登錄，並勾選同意訪問微信的基本信息；之後在王者榮耀內，小明就可以使用自己微信內的頭像，暱稱，還可以邀請到微信內的好友進行組隊遊戲。
oauth2在這個例子中解決了什麼問題呢
小明在微信有賬號，王者榮耀內沒有賬號。通過微信授權的方式，小明在王者榮耀省去了註冊登錄的過程，甚至可以邀請到微信好友進行組隊遊戲
理論
oauth2是什麼
OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.
意思是說，oauth2是一個授權的標準協議。通過提供特定的授權流程來簡化客戶端開發。
四種角色
resource owner
An entity capable of granting access to a protected resource.
When the resource owner is a person, it is referred to as an
end-user.
資源所有者，例子中的小明同學
resource server
The server hosting the protected resources, capable of accepting
and responding to protected resource requests using access tokens.
資源服務器，例子中微信的資源，包括小明的微信頭像，暱稱，好友列表這些個人信息
client
An application making protected resource requests on behalf of the
resource owner and with its authorization. The term “client” does
not imply any particular implementation characteristics (e.g.,
whether the application executes on a server, a desktop, or other
devices).
客戶端，例子中的遊戲：王者榮耀
authorization server
The server issuing access tokens to the client after successfully
authenticating the resource owner and obtaining authorization.
授權服務器，用於頒發訪問token，例子中的微信授權服務器。
授權服務器和資源服務器可以是同一個服務器，也可以是不同的服務器。上面的例子中，資源服務器和授權服務器都是微信服務器。
協議流程
+--------+ +---------------+
| |--(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 ---| |
+--------+ +---------------+
A：上圖中客戶端直接向資源所有者發起授權請求。最好是通過授權服務器作爲中介向資源所有者發起請求，如上面小明的例子，王者榮耀客戶端通過微信授權服務器向小明發起授權請求。
B：客戶端收到資源所有者的授權許可。授權許可類型可以下文介紹的四種方式之一，具體選擇哪一種要根據客服端請求授權的方式和授權服務器支持的方式。如上面的例子中，王者榮耀客戶端收到客戶的授權許可。
C：客戶端通過授權許可向授權服務器發起獲取訪問令牌的請求。例子中王者榮耀客戶端向微信服務器發起請求。
D：授權服務器進行身份認證和驗證授權許可之後，頒發訪問令牌。例子中微信服務器驗證王者榮耀客戶端獲取了小明的授權之後，頒發訪問令牌給王者榮耀客戶端。
E：客戶端攜帶訪問令牌向資源服務器請求受保護的資源。王者榮耀客戶端向微信服務器請求暱稱頭像等資源。
F：資源服務器返回受保護的資源。微信服務器驗證訪問令牌，如果有效，則正確響應。
四種授權許可類型
授權碼Authorization Code
最常用的一種方式，上面小明微信授權的例子就是。
1.客戶端通過授權服務器作爲中介向資源所有者發起授權請求。
2.在步驟2.2返回授權碼之前，授權服務器會對資源所有者的身份進行驗證。
3.步驟3.1通過客戶端直接訪問授權服務器獲取訪問令牌，越過了資源所有者的代理：瀏覽器，保證了訪問令牌不會被資源所有者暴露給其他人。
簡化模式Implicit
Implicit是一種簡化的授權碼方式。針對一些特定的客戶端（使用諸如JavaScript這類腳本語言瀏覽器客戶端）做了優化，授權服務器省略了頒發授權碼的過程，而是直接頒發訪問令牌。
簡化模式提升了某些客戶端的響應能力和效率（諸如一些瀏覽器內的應用程序）。
但要注意存在的一些安全隱患，能使用授權碼方式的場景儘量使用授權碼。
資源所有者密碼授權方式Resource Owner Password Credentials
資源所有者直接將賬號密碼告訴客戶端，客戶端通過賬號密碼訪問授權服務器獲取訪問令牌。
一般用於資源所有者和客戶端之間高度信任的場景。
客戶端授權方式Client Credentials
受保護資源在客戶端控制下的場景，客戶端憑證作爲授權許可。可用於後臺api服務消費者。
實踐
可參考JavaBigData1024的文章
後面再抽時間代碼實踐
總結
oauth2授權協議，並不是認證協議。後續學習OIDC身份認證
參考文獻
https://tools.ietf.org/html/rfc6749#page-6