輕鬆理解OAuth2.0協議(多圖)

前言

最近有一個簡單的需求須要在一個微信公衆號外部的H5頁面中使用微信登陸(接入),同時還要在內部使用第三方支付接口完成支付(不使用微信支付).

無奈隊友不給力只好本身研究了一下具體的流程,不出意料的是這兩個接入商提供的SDK不一樣另外微觀操做不一樣,可是基本流程是類似的.

理解了其中的規則以爲頗有意思,邊萌生出了使用簡單的幾張圖片來解釋OAuth2.0協議的想法.

ps:素材是使用note8+autodesk畫的,合成使用的是Photoshop,對於我這種手殘真的累死了,下次能寫字就不發圖了( ҂˘ _˘ ).

注意:本文章不是介紹微信以及第三方支付接入具體的實現的文章.

什麼是OAuth2.0協議(它能幹什麼)

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

那什麼是開放受權,最直接的例子就是在登陸一些網站的時候使用第三方帳戶進行登陸,相信這些場景相信你們都再熟悉不過了.

爲何使用OAuth2.0協議

舉一個簡單的例子.

咱們正在維護一個網上商城,當用戶點擊購買的時候,咱們想借用第三方支付來向咱們帳戶裏打錢,而不用花鉅額的力氣再去開發一套支付系統.

如今用戶點擊付錢了你會哪一個選項來提供支付功能呢?

選項A:

<a href="www.xxx.com/pay/account/123456">點擊支付</a>

這個方法不錯,幾乎0成本,但是它有以下的缺陷(使用這種你是認真的嗎?):

• 你不知道用戶是否支付成功從而沒法肯定訂單是否完成
• 你不知道用戶輸入的金額
• 你不知道是誰向你支付,買的什麼東西
• 沒有這種可愛的用戶(大概吧)

選項B:
直接和用戶索要第三方支付的帳戶和密碼,而後由後臺進行代理購買.

提出這個方案的人簡直是天才,他完全的解決了沒法確認是誰支付的問題,可是有以下的不足:

• 傳輸用戶的賬號密碼不安全
• 由上面引起的種種不安全
• 你不安全(重要)

選項C:
使用AUTH2.0協議.

用戶,第三方平臺和我(服務商)的想法🤔

用戶

使用第三方帳戶登陸一個新的網站,對於用戶來講無非就是有以下的需求:

• 懶的註冊
• 想利用這種第三方登入的便利性(例如:使用QQ登入百度網盤的用戶免費獲取2T空間)

第三方平臺

那麼對於第三方就拿騰訊來講吧,假如我有一個博客,要使用QQ登入,對於騰訊來講如何作才能保證用戶的安全呢?

• 首先確認要求接入的服務商提供者的信息資歷等(必要的時候能夠查水錶😂)
• 而後給要求接入的服務商一個惟一憑證,標明服務商身份

服務商(我)

咱們要作的就是將這二者進行鏈接起來,而具體的方式以下:

正文

通常來講你會獲得以下的兩個參數:

• appid 表明你的應用惟一ID
• appsecret 對應的密鑰

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

注意:第三方平臺給你的不必定是APPID,個人意思不是連名字都徹底同樣,有的平臺給的參數多有的給的少,總之都是用於驗明身份的.

用戶不必定第一次受權就是登陸操做,這裏咱們以登陸爲例.

在這個流程中服務器(我)接受到了用戶想要第三方登陸的請求,咱們使用以前獲取的APPID(不一樣平臺叫法和參數可能不一樣),而後拼接爲成第三方平臺指定的url而後直接重定向到這個url.

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

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

參數:

• appid 咱們的應用對於第三方平臺的惟一id
• redirect 用戶贊成受權後被重定向的地址,通常來講都是本應用的首頁或者登陸頁面,在本例中就是www.sss.com/login這個地址.
• 其餘參數 根據第三方平會有不一樣的額外參數.

而後將用戶重定向到這個url中,此時用戶會跳轉到www.xxx.com.

注意:重定向是一個很重要的參數,當用戶贊成受權後第三方服務器將會重定向到這個地址.

這個時候用戶被重定向到了www.xxx.com上,頁面提示用戶是否要向www.sss.com進行受權.

若是用戶贊成了受權,那麼第三方服務器會重定向url到咱們指定的url上,在本例中就是www.sss.com/login而且帶上一個code參數.

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

www.sss.com/login?code=xxxxx

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

咱們再次拼接一個url(不一樣平臺地址規則不一樣),可是通常來講這個請求會有以下的參數:

• code 用戶受權後重定向帶回來的code
• appid 應用惟一id
• appsecret 應用對應的密鑰

在這個例子中咱們請求服務器的url多是這個樣子的:

www.xxx.com/oauth2/access_token?appid=xxxx&secert=xxxx&code=xxxx

若是一切順利在這個階段咱們就能夠獲取第三方平臺響應的一個accesstoken,這個accesstoken表明着用戶對於這個應用的受權.

除此之外你還會獲取到用戶的基本信息例如用戶的惟一id之類的.

後續的請求用戶的信息須要使用accesstoken進行請求.

如今咱們來完成用戶的登陸這個流程.

利用accesstoken咱們向服務器獲取了用戶的名字,顯示在了咱們的應用中.

後續的資源獲取就是這個模式(不一樣平臺資源獲取地址以及方式有可能稍有不一樣).

在用戶的資源請求中對於敏感的操做,都不會在前端中完成,都是代交由服務器進行資源獲取.

注意

1. 用戶的會話持久依然是由你來作的,當用戶首次受權登陸後你就應該記住用戶,而不是每次登陸時候都進行受權.
2. accesstoken通常都會有過時時間,使用一段時間後失效,因此在某個環節你還能夠獲得一個refreshtoken用於刷新accesstoken.

參考&引用

http://www.ruanyifeng.com/blo...
https://www.cnblogs.com/flash...
https://blog.csdn.net/hel_wor...
https://blog.csdn.net/wang839...