理解OAuth2 0認證

oauth協議為使用者資源的授權提供了乙個安全的、開放而又簡易的標準。與以往的授權方式不同之處是oauth的授權不會使第三方觸及到使用者的帳號資訊（如使用者名稱與密碼），即第三方無需使用使用者的使用者名稱與密碼就可以申請獲得該使用者資源的授權，因此oauth是安全的。oauth是open authorization的簡寫。

oauth本身不存在乙個標準的實現，後端開發者自己根據實際的需求和標準的規定實現。其步驟一般如下：

客戶端要求使用者給予授權

使用者同意給予授權

根據上一步獲得的授權，向認證伺服器請求令牌（token）

認證伺服器對授權進行認證，確認無誤後發放令牌

客戶端使用令牌向資源伺服器請求資源

資源伺服器使用令牌向認證伺服器確認令牌的正確性，確認無誤後提供資源

任何身份認證，本質上都是基於對請求方的不信任所產生的。同時，請求方是信任被請求方的，例如使用者請求服務時，會信任服務方。

所以，身份認證就是為了解決身份的可信任問題。

在oauth中，簡單來說有三方：使用者（這裡是指屬於服務方的使用者）、服務方、第三方應用。

服務方不信任使用者，所以需要使用者提供密碼或其他可信憑據；

服務方不信任第三方，所以需要第三方提供自已交給它的憑據（通常的一些安全簽名之類的就是）；

使用者部分信任第三方，所以使用者願意把自已在服務方裡的某些服務交給第三方使用，但不願意把自已在服務方的密碼交給第三方；

在oauth2.0的流程中，使用者登入了第三方的系統後，會先跳去服務方獲取一次性使用者授權憑據，再跳回來把它交給第三方，第三方的伺服器會把授權憑據以及服務方給它的的身份憑據一起交給服務方，這樣，服務方一可以確定第三方得到了使用者對此次服務的授權（根據使用者授權憑據），二可以確定第三方的身份是可以信任的（根據身份憑據），所以，最終的結果就是，第三方順利地從服務方獲取到了此次所請求的服務。

從上面的流程中可以看出，oauth2.0完整地解決掉了使用者、服務方、第三方在某次服務時這三者之間的信任問題。

resource owner（資源擁有者：使用者）

client （第三方接入平台：請求者）

resource server （伺服器資源：資料中心）

authorization server （認證伺服器）

oauth2.0基本流程：

authorization server得到使用者同意後，返回token，

客戶端必須得到使用者的授權（authorization grant），才能獲得令牌（access token）。oauth 2.0定義了四種授權方式。

授權碼模式（authorization code）是功能最完整、流程最嚴密的授權模式。它的特點就是通過客戶端的後台伺服器，與"服務提供商"的認證伺服器進行互動。

它的步驟如下：

使用者訪問客戶端，後者將前者導向認證伺服器。

使用者選擇是否給予客戶端授權。

假設使用者給予授權，認證伺服器將使用者導向客戶端事先指定的"重定向uri"（redirection uri），同時附上乙個授權碼。

客戶端收到授權碼，附上早先的"重定向uri"，向認證伺服器申請令牌。這一步是在客戶端的後台的伺服器上完成的，對使用者不可見。

認證伺服器核對了授權碼和重定向uri，確認無誤後，向客戶端傳送訪問令牌（access token）和更新令牌（refresh token）。

下面是上面這些步驟所需要的引數。

步驟1:客戶端申請認證的uri，包含以下引數：

例子:

步驟3：伺服器回應客戶端的uri，包含以下引數：

例子：

步驟4：客戶端向認證伺服器申請令牌的http請求，包含以下引數：

例子：

步驟5：認證伺服器傳送的http回覆，包含以下引數：

例子：

如果使用者訪問的時候，客戶端的"訪問令牌"已經過期，則需要使用"更新令牌"申請乙個新的訪問令牌。

客戶端發出更新令牌的http請求，包含以下引數：

例子：

post /token http/1.1

host: server.example.com authorization: basic czzcagrsa3f0mzpnwdfmqmf0m2jw grant_type=refresh_token&refresh_token=tgzv3jokf0xg5qx2tlkwia

理解OAuth2 0認證

OAuth2 0認證授權

OAuth2 0的認證流程

OAuth 2 0 認證框架介紹

理解OAuth2 0認證

OAuth2 0認證授權

OAuth2 0的認證流程

OAuth 2 0 認證框架介紹

相關推薦