爬蟲模擬登入—OAUTH的詳解

Python資料科學發表於2018-05-10

爬蟲OAuth

作者：xiaoyu

微信公眾號：Python資料科學

知乎：python資料分析師

解讀爬蟲中HTTP的祕密（基礎篇）

解讀爬蟲中HTTP的祕密（高階篇）

Python爬蟲之模擬登入京東商城

前兩篇分享了HTTP的基本概念和高階用法，以及京東模擬登入的實戰內容。本篇博主將會繼續與大家分享HTTP中的另一個有趣內容：OAUTH，它也是在爬蟲的模擬登入中可能會用到的，下面給大家詳細介紹一下。

OAUTH的定義

引自百度百科的定義：

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

目前，最新的OAUTH協議使用2.0版本，具體內容被記錄在RFC6749標準中，可參考連結：tools.ietf.org/html/rfc674…。

OAUTH的應用

一個簡單而不陌生的例子。

我們平時訪問某個網站或論壇，如果進行一些個人操作，網頁一般會彈出讓我們先登入的提示。如果這時候我沒有賬號又不想註冊的話，該怎麼辦呢？我們通常會點選一個第三方的小圖示（比如微信）而完成登入。有些網站甚至沒有使用者註冊的功能，完全依靠第三方網站登入獲取使用者資訊。

比如我們使用微博賬號來登入segmentfault網站。

網頁會首先被重定向到微博的登入介面進行登入，我們輸入我們的賬號和密碼後，segementfault網站會根據從微博賬號獲取的資訊（比如你的微博頭像、暱稱、好友列表等）來建立一個使用者。當然，segmentfault是不會知道你的微博密碼的，因為我們必須保證使用者登入資訊的安全性而不能將密碼明文出去。這一系列的安全性的授權操作都源於使用了OAUTH協議。

其實在這一過程中，OAUTH協議解決了傳統第三方登入方法的一些弊端，比如：

避免了傳統方法中直接使用使用者名稱稱和密碼進行第三方登入的行為，而是通過token的形式使登入過程更安全可靠。
避免了傳統方法中修改密碼會喪失所有第三方程式授權的尷尬。
避免了因任意一個第三方程式被破解而洩露使用者資訊的缺點。

也正是機遇這些，OAUTH就應運而生了。那麼，上述的第三方授權登入過程到底是怎麼實現的呢？這一過程怎麼進行的呢？我們帶著這些問題繼續往下看。

OAUTH實現的思路

通過上面應用的介紹，我們不難發現這其中可大概分為三個物件，分別是：

客戶端（上面的segmentfault）
第三方（上面的weibo）
使用者（我們自己）。

清楚這個之後，我們看看OAUTH授權的大概思路。

使用OAUTH協議，客戶端不會與第三方登入網站直接聯絡，而是先通過一個授權的中間層來建立聯絡（有的網站將授權伺服器和資源伺服器分開使用，有的一起使用）。在這個授權層下，使用者密碼等安全資訊不會洩露給客戶端，而是通過反饋一個臨時的令牌token來代替使用者資訊完成授權。token相當於一把鑰匙，並且區別於使用者密碼，token令牌是經過加密演算法生成的，一般的很難破解。
另外，使用者可以指定token令牌的許可權範圍和有效期，以適度的開放資源。
得到授權後，客戶端就會帶著token，並根據使用者規定的許可權範圍和有效期來規矩的獲取資源資訊。

這只是一個大體的思路，說白了就是通過一個授權層隔離了客戶端與使用者資訊，並在授權層基礎上使用了一把安全的鑰匙來代替使用者完成授權。

OAUTH的執行流程

基於這個思路，RFC6749標準規定了四種不同的授權流程供選擇，分別是：

授權碼模式（authorization code）
簡化模式（implicit）
密碼模式（resource owner password credentials）
客戶端模式（client credentials）

上面提到的微博使用OAUTH2.0授權碼模式完成授權。其它客戶端進行第三方登入之前，需要先在微博開放平臺上註冊一個應用，在應用裡填寫自己的資訊。註冊完後，開放平臺會給客戶端（比如上面提到的segmentfault）頒發一個client_id和一個APP Secret，供授權請求的使用。

下面將詳細介紹微博的授權流程，即授權碼模式，其它模式可以參考官方文件：https://tools.ietf.org/html/rfc6749。

OAUTH的詳細實現過程

下面是OAUTH2.0協議的詳細流程圖：

博主以上面segmentfault通過微博第三方登入為例來詳細說明OAUTH授權流程。

<1> 第一步

首先使用者點選微博圖示進行第三方登入，然後頁面跳轉到微博登入介面等待使用者輸入賬號密碼授權。

登入介面url如下：

https://api.weibo.com/oauth2/authorize?client_id=1742025894&redirect_uri=https%3A%2F%2Fsegmentfault.com%2Fuser%2Foauth%2Fweibo&scope=follow_app_official_microblog
複製程式碼

客服端通過application/x-www-form-urlencoded格式並使用 UTF8編碼 將下列引數加入到 query string 中來建立URI請求。

client_id：即segmentfault在微博開放平臺申請的應用ID號（需要）
redirect_uri：使用者授權後需要跳轉到的url地址（可選）
scope：使用者授權的許可權範圍和有效期（可選）

<2> 第二步

頁面跳轉到上一步驟的redirect_uri地址並在末尾新增一個授權碼code值，在後面步驟中會用code值來換取token。

跳轉地址如下：

https://segmentfault.com/user/oauth/weibo？code=e7ec7daeb7bbf8cb9d622152cd449ae0
複製程式碼

引數說明：

code：授權碼，且只能被客戶端使用一次，否則會被授權伺服器拒絕。該碼與上面的應用ID和重定向URI，是一種對映關係。

這也驗證了reponse_type是code型別的正確性。

<3> 第三步

segmentfault客戶端使用授權的code來獲得鑰匙token。

獲取token可以通過對微博OAuth2的access_token介面進行POST請求完成，請求連結：https://api.weibo.com/oauth2/access_token

當然，請求還需要攜帶以下引數才行。

client_id：申請應用時分配的AppKey

client_sceret：申請應用時分配的AppSecret

grant_type：請求的型別，填寫authorization_code

code：呼叫authorize獲得的code值

redirect_uri：回撥地址，需需與註冊應用裡的回撥地址一致

<4> 第四步

返回上步請求獲得的token資訊。一個例項結果如下：

{
       "access_token": "ACCESS_TOKEN",
       "expires_in": 1234,
       "remind_in":"798114",
       "uid":"12341234"
 }
複製程式碼

引數說明：

access_token：使用者授權的唯一票據，用於呼叫微博的開放介面，同時也是第三方應用驗證微博使用者登入的唯一票據，第三方應用應該用該票據和自己應用內的使用者建立唯一影射關係，來識別登入狀態，不能使用本返回值裡的UID欄位來做登入識別。

expires_in：access_token的生命週期，單位是秒數。

remind_in：access_token的生命週期。

uid：授權使用者的UID，本欄位只是為了方便開發者，減少一次user/show介面呼叫而返回的，第三方應用不能用此欄位作為使用者登入狀態的識別，只有access_token才是使用者授權的唯一票據。