什么是OAuth？
OAuth一個開放的授權標准，允許用戶在不提供關鍵信息（如賬號，密碼）給第三方應用的前提下，讓第三方應用去訪問用戶在某網站上的資源（如頭像，用戶昵稱等）。
OAuth分為OAuth1.0和OAuth2.0兩個版本，后來隨着OAuth2.0被使用的越來越廣泛，OAuth1.0逐漸退出舞台（當然仍有少部分系統在使用1.0授權標准）。下面我們圍繞OAuth2進行展開。
OAuth 2.0致力於簡化客戶端開發人員的工作，同時為Web應用程序，桌面應用程序，移動電話和客廳設備提供特定的授權流程。
我們以博客園登錄為例：
新同學小明想在“博客園”發表文章，這時候他進入登錄頁面，“博客園”登錄首頁需要小明提供用戶名和密碼才允許小明登入。
而由於小明是第一次使用“博客園”，他對博客園可能不是很信任，於是他想通過下方的他信任QQ應用直接登錄。
來到這里我們發現，通過授權，“博客園”將獲得小明在QQ應用中的資源（昵稱，頭像，性別），並成功登錄“博客園”，而並不需要提供用戶名和密碼給“博客園”。
上例中“博客園”就是所謂的第三方應用，而QQ就是提供受保護資源的某個應用。
OAuth2四個參與角色
1.資源所有者（Resource Owner）：資源的擁有者（上例中：小明）
2.資源服務器（Resource Server）：資源所在的服務器（上例中：QQ應用）
3.授權服務器（Authorization Server）：用於驗證client（第三方應用）的真實性，提供授權碼和令牌token。授權服務器可單獨部署，也可以和資源服務器一起部署。
4.第三方應用（Client）：訪問受保護資源的客戶端，上例中：博客園
這里，很多同學會對“授權服務器”存在疑惑，上例中博客園登錄流程並未體現授權服務器啊？我們接着往下看
OAuth2標准授權流程
結合OAuth2經典流程圖，我們一下再來看下小明登錄“博客園”的流程。
（A）第三方應用（client）“博客園”向（資源擁有者）小明發起授權請求，即小明點擊博客園登錄頁中的QQ登錄。
（B）QQ登錄授權頁面，小明登錄自己的QQ賬號，同意授權給“博客園”，並返回授權許可憑證。
（C）第三方應用（client）“博客園”拿着步驟（B）獲取的授權許可憑證，向授權服務器發起請求。
（D）授權服務器同意第三方應用（client）“博客園”的請求，並返回一個令牌Token。
（E）第三方應用（client）“博客園”拿着Token請求（資源服務器）QQ應用中的昵稱，頭像等資源
（F）（資源服務器）QQ應用驗證Token通過，並返回資源給第三方應用（client）“博客園”
通過上述流程，我們可以看出，當QQ授權同意后，並不是馬上就將QQ應用中的資源返回給第三方客戶端的，而是需要客戶端拿着授權許可憑證，向授權服務器請求並獲取最終的鑰匙Token，然后才能獲得受保護資源。
顯然，授權服務器充當了一個驗證client，並頒發token令牌的服務角色。
那么授權許可憑證到底是什么呢？
OAuth2授權許可憑證
1.授權碼（Authorization Code）：
該模式目前是功能最完整、流程最嚴密的授權模式。一般需要client有專門的后端server，根據獲取的授權碼code在后端server請求令牌token。
上例中博客園登錄授權就是用的“授權碼模式”，交互流程如下：
1）博客園向小明發起QQ授權請求。 2）QQ授權驗證同意后，根據博客園提供的Redirect_url返回，並帶上授權碼code 3）博客園前端根據返回的url獲取授權碼code，並在后端server向授權服務器發起請求獲取token 4）授權服務驗證通過，並以json格式返回token 5）博客園再根據token請求QQ應用中獲取受保護資源（頭像，昵稱等）
步驟(1)，授權請求（Authorization Request）：
client需提供如下主要參數：
1.client_id：必填，第三方應用唯一標識ID 2.redirect_uri：必填，授權同意后，重定向地址URL 3.response_type：必填，授權碼模式下固定值為“code” 4.state：選填，一個狀態碼，可用於防止跨站請求偽造（CSRF）攻擊。客戶端發起授權請求時會生成一個狀態碼與客戶端綁定，授權請求成功后會將該state原樣返回 5.scope：選填，標識授權范圍
例如博客園向QQ發起授權請求：
https://graph.qq.com/oauth2.0/show?which=Login&display=pc
&client_id=101880508
&scope=get_user_info
&response_type=code
&redirect_uri=***
&state=*****
擴展：跨站請求偽造（CSRF）攻擊：用戶登錄了A可信網站，認證信息保存在瀏覽器cookie中。當用戶訪問攻擊者創建的B網站時，用戶認證信息仍有效，攻擊者通過在B網站發送一個偽造的請求提交到A網站服務器上，讓A網站服務器誤以為請求來自於自己的網站。
步驟(2)，授權請求同意后，返回信息：
1.code：授權碼 2.state：原樣返回，client提交的state狀態碼
步驟(3)，根據授權碼code，后端請求token，client需提供如下參數
1.grant_type：必填。授權碼模式，固定值“authorization_code”。 2.code : 必填。授權同意后返回的授權碼。 3.redirect_uri：必填。授權同意后，重定向地址URL
4.client_id：必填。第三方應用唯一標識ID。
5.client_secret：必填。第三方應用授權申請的秘鑰。
例如：
POST /oauth/token HTTP/1.1 Host: authorization-server.com grant_type=authorization_code &code=xxxxxxxxxxx &redirect_uri=https://example-app.com/redirect &client_id=xxxxxxxxxx &client_secret=xxxxxxxxxx
步驟(4)，授權認證通過，返回主要參數。
1.access_token：訪問令牌。 2.refresh_token：刷新令牌。 3.expires_in：令牌過期時間。
4.token_type：令牌類型。
其中刷新令牌refresh_token的作用是，當訪問令牌token失效時，無需重新發起授權獲取新的token,根據刷新令牌直接請求授權服務，就可以獲取新的令牌。
2.隱式許可(Implicit)：
授權碼模式的簡化應用，跳過了獲取授權碼code的過程，直接獲取token。一般用於沒有后端的Client。
如果博客園使用該模式，其工作流程：
1）博客園向小明發起QQ授權請求。 2）QQ授權驗證同意后，根據博客園提供的Redirect_url返回，並帶上令牌token
3）博客園再根據token請求QQ應用中獲取受保護資源（頭像，昵稱等）
步驟（1），授權請求參數和授權碼模式參數一樣，唯一不同的參數是response_type，Implicit模式下固定值為“token”。
步驟（2），授權請求同意后，返回信息：
1.access_token：訪問令牌。
2.token_type：令牌類型。
3.expires_in：令牌過期時間。
注：隱式授權模式頒發的令牌，不提供refresh刷新令牌
URL格式：
格式：https://a.com/callback#token=ACCESS_TOKEN
注意，令牌的位置是 URL 錨點“#”后面，而不是查詢字符串“?”后面，這是因為 OAuth2允許跳轉網址是 HTTP 協議，因此存在"中間人攻擊"的風險，而瀏覽器跳轉時，錨點不會發到服務器，就減少了泄漏令牌的風險。
3.用戶密碼模式(Resource Owner Password Credentials)：
客戶端提供用戶名和密碼，獲取token。前面我們說OAuth2就是為了避免直接提供用戶名和密碼給第三方應用程序而誕生，那么這里又是怎么回事呢？
其實，該授權模式的初衷是為服務自己的應用啟用密碼登錄，用戶使用其用戶名和密碼登錄該服務的網站或本機應用程序，但是絕對不允許第三方應用程序詢問用戶密碼。
授權請求，提供參數：
1.grant_type：必填。該模式下固定值為“password”。 2.username：必填。用戶登陸名。 3.passward：必填。用戶登陸密碼。 4.scope：可填。表示授權范圍。
5.客戶端認證參數：通常如果授權服務管理系統給客戶端頒發了身份秘鑰信息（client_id,client_secret）,那么客戶端發起授權請求時需要攜帶參數client_id和client_secret。或在HTTP Basic auth標頭中接受客戶端client_secret和密碼client_secret
其中，客戶端認證參數：client_id和client_secret主要是用於授權服務驗證客戶端的身份。如果客戶端都沒在授權服務管理系統備案（不需要驗證客戶端身份），那么授權請求就不需要這兩個參數。備案又是什么呢？大家請留意文章末尾。
以postman請求token為例：
第一種方式：將client_id和client_secret作為請求體參數
第二種方式：在HTTP Basic auth請求頭中單獨驗證client_secret和client_secret
授權請求同意后，返回主要參數：
1.access_token：訪問令牌。 2.token_type：令牌類型。 3.expires_in：令牌過期時間。 4.scope：授權范圍
4.客戶端模式(Client Credentials)：
當第三方應用程序請求訪問令牌以訪問其自己的資源（而非代表其他用戶去訪問資源）時，使用該模式。此時第三方應用程序將自己當成資源所有者，直接請求授權服務器獲取令牌token。
授權請求，提供參數：
1.grant_type：必填。該模式下固定值為“client_credentials”。 2.scope：可填。表示授權范圍。
3.客戶端認證：必填，包含參數client_id和client_secret；或在HTTP Basic auth標頭中接受客戶端client_secret和密碼client_secret
以postman請求token為例：
第一種方式：將client_id和client_secret作為請求體參數
第二種方式：在HTTP Basic auth請求頭中單獨驗證client_secret和client_secret
兩種方式效果一致，都是通過client_id和client_secret，讓授權服務器驗證客戶端的身份。
授權請求同意后，返回參數：
1.access_token：訪問令牌。
2.token_type：令牌類型。 3.expires_in：令牌過期時間。 4.scope：授權范圍
擴展：第三方應用發起授權請求時，client_id和client_secret是哪來的呢？
授權服務提供第三方應用的管理：
第三方應用申請令牌之前，都必須先到授權服務系統備案，說明自己的身份，然后會拿到兩個身份識別碼：客戶端 ID（client ID）和客戶端密鑰（client secret）。這是為了防止令牌被濫用，沒有備案過的第三方應用，是不會拿到令牌的。
5.刷新令牌refresh token
前面我們說，當授權請求同意后，通常授權服務器會返回一個刷新令牌refresh token給我們（該返回參數非必選的，由授權服務定制，通常推薦返回該參數）。
當訪問令牌access token 過期后，如果重新發起一遍請求令牌的過程顯然有點麻煩，這時候通過refresh token發起一次請求可以直接獲取新的訪問令牌access token。
請求參數：
1.grant_type：必填。固定值為“refresh_token”。 2.refresh_token：必填。 3.scope：可填。表示授權范圍。 4.客戶端認證：通常如果授權服務管理系統給客戶端頒發了身份秘鑰信息（client_id,client_secret）,那么客戶端發起授權請求時需要攜帶參數client_id和client_secret。或在HTTP Basic auth標頭中接受客戶端client_secret和密碼client_secret。
如果客戶端不需要身份認證，則無需攜帶任何身份認證的信息
例如：
POST /oauth/token HTTP/1.1 Host: authorization-server.com grant_type=refresh_token &refresh_token=xxxxxxxxxxx &client_id=xxxxxxxxxx &client_secret=xxxxxxxxxx
本文，我們結合博客園授權QQ登錄的案例，描述了OAuth2的基本概念，OAuth2的授權流程以及各種授權模式的使用。多動手，多動手，多動手才能加深自己的理解。
附：推薦幾篇值得學習的OAuth2文章