OAuth 2.0詳解

雨點的名字發表於2020-07-18

OAuth 2.0詳解

概念:OAuth(開放授權)是一個開放標準,允許使用者讓第三方應用訪問該使用者在某一網站上儲存的私密的資源(如基本訊息,照片,聯絡人列表),

而無需將 使用者名稱密碼 提供給第三方應用。

一、應用場景

為了理解OAuth的適用場合,這裡舉一個使用第三方賬戶進行登入的例子。

現在一般登陸都會採用 第三方授權 登陸,比較常見就是微信、qq、微博授權登陸。這裡以微信授權登陸為例:

現在我在未註冊的情況下去訪問A網站,A網站 為了提高使用者體驗,可以省去你在這次網站申請註冊的步驟,讓你通過微信授權登陸去拿去你在微信上的基本資訊。

問題就在這裡,如果拿到微信使用者基本資訊給到A網站,直接給A網站我登陸微信的賬號密碼,那麼問題可想而知。

1、這個也太不安全了,我只想給A網站我的在微信上的基本資訊,而不是所有資訊,通過使用者密碼可以獲取我的所有資訊。
2、使用者只有修改密碼,才能收回賦予"A網站"的權力。但是這樣做,會使得其他所有獲得使用者授權的第三方應用程式全部失效。
3、只要有一個第三方應用程式被破解,就會導致使用者密碼洩漏,以及所有被密碼保護的資料洩漏。

OAuth就是為了解決上面這些問題而誕生的。

從上面可以看出主要有三個身份

使用者

使用第三方賬戶登入一個新的網站,對於使用者來說就不需要走複雜的註冊流程。

第三方平臺(微信)

上面來講 微信 就是第三方平臺,那麼對於第三方如何做才能保證使用者的安全呢?

就在A網站在通過微信授權登陸之前,需要提供資質到微信,微信稽核,稽核通過後給要求接入的服務商一個唯一憑證,標明服務商身份。

服務商(A網站)

我們要做的就是將這兩者進行連線起來,先到第三方平臺資質稽核,稽核通過後,使用者去第三方平臺授權登入後,就可以獲取使用者基本資訊,完成登陸。


二、OAuth的思路

這裡還是以 服務商(A網站),和 第三方平臺(微信)授權登入來縷這個思路。

OAuth在 服務商(A網站)第三方平臺(微信) 之間,設定了一個授權層(authorization layer)。服務商 不能直接登入 第三方平臺,只能登入授權層,

以此將使用者與服務商(A網站)區分開來。服務商(A網站) 登入授權層所用的令牌(token),與使用者的密碼不同。使用者可以在登入的時候,指定授權層令牌的許可權範圍和有效期。

服務商(A網站) 登入授權層以後,第三方平臺 根據令牌的許可權範圍和有效期,向 服務商(A網站) 開放使用者儲存的資料。

這裡縷下大致流程

1、接入前準備(資質稽核)

如果一個服務商需要使用第三方平臺的服務,那麼首先是需要向第三方平臺提供資料,第三方平臺稽核通過後,會給服務商一個唯一標識的ID,這樣通過第三方平臺授權的時候,

第三方平臺就知道是哪個商戶了。

OAuth 2.0詳解

一般來說你會得到如下的兩個引數:

appid 代表你的應用唯一ID
appsecret 對應的金鑰

這個部分每家平臺都不一樣,具體如何獲取你的APPID請參考對應平臺的指南.

注意 第三方平臺給你的不一定是APPID,我的意思不是連名字都完全一樣,有的平臺給的引數多有的給的少,總之都是用於驗明身份的.

2、使用者要使用第三方登陸

OAuth 2.0詳解

這裡我們以登入為例.

在這個流程中伺服器(A網站)接受到了使用者想要第三方登入的請求,我們使用之前獲取的APPID(不同平臺叫法和引數可能不同),然後拼接為成第三方平臺指定的url

然後直接重定向到這個url.

OAuth 2.0詳解

例如在這個例子中我們的地址可能長這個樣子:

www.xxx.com/oauth2.0/authorize?appid=123456&redirect=www.sss.com/login

引數:

appid 我們的應用對於第三方平臺的唯一id
redirect 使用者同意授權後被重定向的地址,一般來說都是本應用的首頁或者登入頁面,在本例中就是www.sss.com/login這個地址.
其他引數 根據第三方平會有不同的額外引數.

然後將使用者重定向到這個url中,此時使用者會跳轉到www.xxx.com(因為如果使用者授權成功,你總要回撥服務商介面,來告訴它,已經授權成功).

3、使用者授權成功

使用者授權成功後,微信就會請求上面redirect引數中的介面地址,帶上授權成功的引數code

OAuth 2.0詳解

在這個例子中這個url看起來是這個樣子的

www.sss.com/login?code=xxxxx

4、獲取使用者token(令牌)

此時我們的www.sss.com/login接受到了一個含有code的請求,我們知道這個是一個第三方登入授權後的請求.

我們再次拼接一個url(不同平臺地址規則不同),但是一般來說這個請求會有如下的引數:

code 使用者授權後重定向帶回來的code
appid 應用唯一id
appsecret 應用對應的金鑰

在這個例子中我們請求伺服器的url可能是這個樣子的:

www.xxx.com/oauth2/access_token?appid=xxxx&secert=xxxx&code=xxxx
OAuth 2.0詳解

如果一切順利在這個階段我們就可以獲取第三方平臺響應的一個accesstoken,這個accesstoken代表著使用者對於這個應用的授權.

除此以外你還會獲取到使用者的基本資訊例如使用者的唯一id之類的,後續的請求使用者的資訊需要使用accesstoken進行請求。

5、獲取使用者基本資訊

利用accesstoken我們向伺服器獲取了使用者的名字,顯示在了我們的應用中, 後續的資源獲取就是這個模式(不同平臺資源獲取地址以及方式有可能稍有不同).

OAuth 2.0詳解

6、補充

1、微信認證成功後,我會會把accesstoken存放在cookie中,這樣不用每次都需要使用者去授權認證,而是我們後臺去請問微信,這個時候使用者是不會感知的。
2、accesstoken不是一直有效的,它會有過期時間的,就好比微信掃碼登陸中accesstoken有效時間是2小時。
3、那麼accesstoken時效,是不是就要使用者重新授權登陸了,當然也不是,如果沒2小時都要重新授權登陸那體驗也太差了。這裡會有個叫refresh_token,它是
在你第一次獲取accesstoken一起給你的,也就是說如果你的accesstoken時效了,你還可以通過refresh_token去獲取使用者資訊。這麼說refresh_token的時效時間肯定
要比accesstoken,微信掃碼登陸refresh_token有效時間是30天
4、也就是當refresh_token也時效的時候,才會需要使用者重新授權登陸。

具體的可以看看微信掃碼登陸的官方文件:網站應用微信登入開發指南


參考

1、輕鬆理解OAuth2.0協議(多圖) (非常感謝)

2、OAuth2.0 知多少(偏實戰)



別人罵我胖,我會生氣,因為我心裡承認了我胖。別人說我矮,我就會覺得好笑,因為我心裡知道我不可能矮。這就是我們為什麼會對別人的攻擊生氣。
攻我盾者,乃我內心之矛(22)

相關文章