爬蟲模擬登陸—OAUTH的詳解

時間 2019-11-16

標籤爬蟲模擬登陸 oauth 詳解欄目網絡爬蟲简体版

原文原文鏈接

做者：xiaoyuhtml

微信公衆號：Python數據科學python

知乎：python數據分析師算法

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

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

Python爬蟲之模擬登陸京東商城api

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

OAUTH的定義

引自百度百科的定義：bash

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纔是用戶受權的惟一票據。