oauth2.0受權協議

參考文章

一.OAuth是什麼？

        OAuth的英文全稱是Open Authorization，它是一種開放受權協議。OAuth目前共有2個版本，2007年12月的1.0版（以後有一個修正版1.0a）和2010年4月的2.0版，1.0版本存在嚴重安全漏洞，而2.0版解決了該問題，下面簡單談一下我對OAuth2.0的理解。

OAuth 是一個開放標準，容許用戶讓第三方應用訪問該用戶在某一網站上存儲的私密的資源（如照片，視頻，聯繫人列表），而無需將用戶名和密碼提供給第三方應用。目前，OAuth 的最新版本爲 2.0

OAuth 容許用戶提供一個令牌，而不是用戶名和密碼來訪問他們存放在特定服務提供者的數據。每個令牌受權一個特定的網站（例如，視頻編輯網站)在特定的時段（例如，接下來的2小時內）內訪問特定的資源（例如僅僅是某一相冊中的視頻）。這樣，OAuth 容許用戶受權第三方網站訪問他們存儲在另外的服務提供者上的信息，而不須要分享他們的訪問許可或他們數據的全部內容。

OAuth 2.0 的核心概念

• resource owner：資源全部者，指終端的「用戶」（user）
• resource server：資源服務器，即服務提供商存放受保護資源。訪問這些資源，須要得到訪問令牌（access token）。它與認證服務器，能夠是同一臺服務器，也能夠是不一樣的服務器。若是，咱們訪問新浪博客網站，那麼若是使用新浪博客的帳號來登陸新浪博客網站，那麼新浪博客的資源和新浪博客的認證都是同一家，能夠認爲是同一個服務器。若是，咱們是新浪博客帳號去登陸了知乎，那麼顯然知乎的資源和新浪的認證不是一個服務器。
• client：客戶端，表明向受保護資源進行資源請求的第三方應用程序。
• authorization server： 受權服務器， 在驗證資源全部者並得到受權成功後，將發放訪問令牌給客戶端。

 

二.OAuth2.0有什麼用？

使用 OAuth 2.0 認證的的好處是顯然易見的。你只須要用同一個帳號密碼，就能在各個網站進行訪問，而免去了在每一個網站都進行註冊的繁瑣過程。

簡單歸納，就是用於第三方在用戶受權下調取平臺對外開放接口獲取用戶相關信息。

OAuth引入了一個受權環節來解決上述問題。第三方應用請求訪問受保護資源時，資源服務器在獲准資源用戶受權後，會向第三方應用頒發一個訪問令牌(AccessToken)。該訪問令牌包含資源用戶的受權訪問範圍、受權有效期等關鍵屬性。第三方應用在後續資源訪問過程當中須要一直持有該令牌，直到用戶主動結束該次受權或者令牌自動過時。

 

 

三.認證受權過程

一、 服務提供方，用戶使用服務提供方來存儲受保護的資源，如照片，視頻，聯繫人列表。如QQ，微信

二、 用戶，存放在服務提供方的受保護的資源的擁有者。如QQ帳號，微信帳號

三、 客戶端，要訪問服務提供方資源的第三方應用，一般是網站，如提供照片打印服務的網站。在認證過程以前，客戶端要向服務提供者申請客戶端標識。如：58同城，轉轉，豆瓣等可使用QQ，微信帳號登錄到這些第三方應用，還能看到微信中的好友。

 

 

四.詳解OAuth2.0的受權碼簡化模式？

簡單歸納，就是用於第三方在用戶受權下調取平臺對外開放接口獲取用戶相關信息。

有三個關鍵字：第三方，用戶，平臺，關係以下圖

 

 

 

看起來很簡單對吧，其實受權的部分，要比上圖展現的複雜一丟丟，下面來說解一下受權的部分。

        首先，有個問題，就拿微博平臺來講吧，不能說隨便一個第三方過來要求申請用戶資源，微博平臺就去用戶那問一句是否授予權限吧，微博大哥能這麼隨便？因此第三方須要去想要請求的接口所在平臺去報備一下，也就是告訴平臺：個人xxx地址想要申請使用你的接口，能夠嗎？等平臺審覈經過以後，會下發一組appid+appkey，第三方持憑此就有資格去請求該平臺的接口了。

        第三方的準備工做作好了，下面就是具體運做流程了。（各大平臺大多使用受權碼模式——Authorization Code，由於它相比其它幾種模式更爲嚴謹，這裏我僅分析一下該模式的原理）

        這裏咱們假設一個場景，就是想用‘雲打印’來打印本身‘微博的關注列表’。

簡圖以下：

 

詳圖以下：

在第②，④，⑥，⑧步中，分別用到了雲打印在微博平臺上得到的appid+appkey。關於每一步請求所須要的一系列參數這裏就不一一列舉了，官方文檔很是詳細，這裏僅說明一下請求code和請求access token時重要的參數。

        第④步參數：

                      response_type：指受權類型，必選，這裏填固定值‘code’

                      client_id：指客戶端id，必選，這裏填在平臺報備時獲取的appid

                      redirect_uri：指重定向URI，可選

                      scope：指申請的權限範圍，可選

                      state：指客戶端當前狀態，可選，若填了，則認證服務器會原樣返回該值

 

        第⑥步參數：

                      grant_type：指使用哪一種受權模式，必選，這裏填固定值‘authorization_code’

                      code：指從第⑤步獲取的code，必選

                      redirect_uri：指重定向URI，必選，這個值須要和第④步中的redirect_uri保持一致

 

                      client_id：指客戶端id，必選，這裏填在平臺報備時獲取的appid

                      client_secret：指客戶端密鑰，必選，這裏填在平臺報備時獲取的appkey

 

        第⑧步參數：

                      access_token：指訪問令牌，必選，這裏填第⑦步獲取的access_token

                      token_type：指令牌類型，必選，大小寫不敏感，bearer類型 / mac類型

                      expires_in：指過時時間，單位秒，當其餘地方已設置過時時間，此處可省略該參數

                      refresh_token：指更新令牌，可選，用即將過時token換取新token

                      scope：指權限範圍，可選，第④步中若已申請過某權限，此處可省略該參數

 

到這裏，OAuth2.0 受權碼模式的認證過程就完成了，原理還算比較簡單，就是較爲繁瑣，可是不算難。

 

注意：1.code時效較短，多爲10s-10min，每次得到的code僅可以使用一次，且code與client_id和redirect_uri有 一一對應關係。

          2.access token 有過時時間，多爲10-15天。（過時處理有2種，請求用戶從新受權/refreshToken，通常多用從新受權。）

          3.在請求時，參數中包含重定向地址的，須要和第三方在受權方平臺報備時留的地址前部一致

          4.關於token_type的兩種類型有什麼區別，有個博客寫的很詳細，推薦閱讀：www.cnblogs.com/XiongMaoMengNan/p/6785155.html

此處奉上找了很久才找到的OAuth2 RFC6749中文翻譯：http://colobu.com/2017/04/28/oauth2-rfc6749/

本人能力有限，錯誤之處，敬請指正。

--------------------- 做者：張勝楠 來源：CSDN 原文：https://blog.csdn.net/tclzsn7456/article/details/79550249?utm_source=copy 版權聲明：本文爲博主原創文章，轉載請附上博文連接！

 

 

 

 

 

標準的認證過程 
OAuth認證和受權的過程以下: 
1、用戶訪問第三方網站網站，想對用戶存放在服務商的某些資源進行操做。 
2、第三方網站向服務商請求一個臨時令牌。 
3、服務商驗證第三方網站的身份後，授予一個臨時令牌。 
4、第三方網站得到臨時令牌後，將用戶導向至服務商的受權頁面請求用戶受權，而後這個過程當中將臨時令牌和第三方網站的返回地址發送給服務商。 
5、用戶在服務商的受權頁面上輸入本身的用戶名和密碼，受權第三方網站訪問所相應的資源。 
6、受權成功後，服務商將用戶導向第三方網站的返回地址。 
7、第三方網站根據臨時令牌從服務商那裏獲取訪問令牌。 
8、服務商根據令牌和用戶的受權狀況授予第三方網站訪問令牌。 
9、第三方網站使用獲取到的訪問令牌訪問存放在服務商的對應的用戶資源。