OAuth2.0 入門與進階

1、基礎知識

一、OAuth產生背景

　　不少網站、APP 弱化甚至沒有搭建本身的帳號體系，而是直接使用社會化登陸的方式，這樣不只免去了用戶註冊帳號的麻煩、還能夠獲取用戶的好友關係來加強自身的社交功能。

　　好比咱們可使用微博登陸簡書，簡書會自動將你的微博頭像設置爲你的簡書頭像，將你的微博暱稱設置爲你的簡書暱稱，甚至還能夠獲取你微博中的好友列表，提示你哪些朋友已經在使用簡書，這是如何作到的呢？

最傳統的辦法是讓用戶直接在簡書的登陸頁面輸微博的帳號和密碼，簡書經過用戶的帳號和密碼去微博那裏獲取用戶數據，但這樣作有不少嚴重的缺點：

• 簡書須要明文保存用戶的微博帳號和密碼，這樣很不安全。
• 簡書擁有了獲取用戶在微博全部的權限，包括刪除好友、給好友發私信、更改密碼、註銷帳號等危險操做。
• 用戶只有修改密碼，才能收回賦予簡書的權限。可是這樣作會使得其餘全部得到用戶受權的第三方應用程序所有失效。
• 只要有一個第三方應用程序被破解，就會致使用戶密碼泄漏，以及全部使用微博登陸的網站的數據泄漏。

爲了解決以上的問題，OAuth 協議應運而生。

二、定義

　　OAuth2.0（開放受權）是一個關於受權的開放的網絡協議。

　　--->容許用戶讓第三方應用訪問該用戶在某一網站上存儲的的資源（如：照片，視頻，聯繫人列表），而無需將用戶名和密碼提供給第三方應用。

　　--->OAuth是一個關於受權（Authorization）的開放網絡標準，目前的版本是2.0版。注意是Authorization(受權)，而不是Authentication(認證)。用來作Authentication(認證)的標準叫openid connect。

三、基本原理

　　OAuth在第三方應用與服務提供商之間設置了一個受權層。第三方應用不能直接登陸服務提供商，只能登陸受權層，以此將用戶與客戶端區分開來。第三方應用登陸受權層所用的令牌，與用戶的密碼不一樣。用戶能夠在登陸受權的時候，指定受權層令牌的權限範圍和有效期。 
第三方應用登陸受權層之後，服務提供商根據令牌的權限範圍和有效期，向第三方應用開放用戶資源。

四、做用

　　讓客戶端安全可控地獲取用戶的受權，與服務提供商之間進行交互。能夠免去用戶同步的麻煩，同時也增長了用戶信息的安全。

五、經常使用應用場景

• 用OAuth來實現第三方應用對咱們API的訪問控制；
• 登陸第三方應用（APP或網頁）時，常常會採用其餘用戶登陸方式，好比QQ，微博，微信的受權登陸（QQ用戶登陸）。

六、協議流程

　　（A）用戶打開客戶端之後，客戶端要求用戶給予受權。

　　（B）用戶贊成給予客戶端受權。

　　（C）客戶端使用上一步得到的受權，向認證服務器申請令牌。

　　（D）認證服務器對客戶端進行認證之後，確認無誤，贊成發放令牌。

　　（E）客戶端使用令牌，向資源服務器申請獲取資源。

　　（F）資源服務器確認令牌無誤，贊成向客戶端開放資源。

　　不難看出來，上面六個步驟之中，B是關鍵，即用戶怎樣才能給於客戶端受權。有了這個受權之後，客戶端就能夠獲取令牌，進而憑令牌獲取資源。

七、客戶端的受權模式

　　----客戶端獲取受權的四種模式

客戶端必須獲得用戶的受權（authorization grant），才能得到令牌（access token）。OAuth 2.0定義了四種受權方式。

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

（1）受權碼模式（authorization code）

　　功能最完整、流程最嚴密的受權模式。它的特色就是經過客戶端的後臺服務器，與"服務提供商"的認證服務器進行互動。

（2）簡化模式（implicit grant type）

　　不經過第三方應用程序的服務器，直接在瀏覽器中向認證服務器申請令牌，跳過了"受權碼"這個步驟，所以得名。全部步驟在瀏覽器中完成，令牌對訪問者是可見的，且客戶端不須要認證。

（3）密碼模式（Resource Owner Password Credentials Grant）

　　用戶向客戶端提供本身的用戶名和密碼。客戶端使用這些信息，向"服務商提供商"索要受權。在這種模式中，用戶必須把本身的密碼給客戶端，可是客戶端不得儲存密碼。這一般用在用戶對客戶端高度信任的狀況下，好比客戶端是操做系統的一部分，或者由一個著名公司出品。而認證服務器只有在其餘受權模式沒法執行的狀況下，才能考慮使用這種模式。

 

（4）客戶端模式（Client Credentials Grant）

　　指客戶端以本身的名義，而不是以用戶的名義，向"服務提供商"進行認證。嚴格地說，客戶端模式並不屬於OAuth框架所要解決的問題。在這種模式中，用戶直接向客戶端註冊，客戶端以本身的名義要求"服務提供商"提供服務，其實不存在受權問題。

 注：web資源：其實就是接口。

 

2、受權碼模式

　　---以使用微博帳號登陸簡書爲示例詳細講解其工做原理

一、原理概要

新浪微博做爲服務提供商，擁有用戶的頭像、暱稱、郵箱、好友以及全部的微博內容，簡書但願獲取用戶存儲在微博的頭像和暱稱，假設它們是三我的：

1. 簡書問新浪微博：我想要獲取用戶 A 的頭像和暱稱，請你提供
2. 微博說：我須要通過用戶Ａ 本人的許可，而後去問用戶 A 是否要受權簡書訪問本身的頭像和暱稱
3. 用戶 A 對微博說：我給簡書一個臨時的鑰匙，若是他給你出示了這把鑰匙，你就把個人資料給他
4. 簡書使用戶給它的鑰匙獲取用戶頭像和暱稱信息。

以上是 OAuth 認證的大概流程。在使用微博受權以前，簡書須要先在微博開放平臺上註冊應用，填寫本身的名稱、logo、用途等信息，微博開放平臺頒發給簡書一個應用 ID 和叫 APP Secret 的密鑰，在實際對接中，會使用到這兩個參數。

注：

• 新浪微博開放平臺便是認證服務器
• 用戶發放code（時間極短）
  認證服務器發放 token（時間長）
• 資源服務器提供用戶資源

 二、詳細流程

接下來分步詳細解釋上圖中每步都作了什麼：

　　1.用戶點擊簡書上的微博登陸按鈕，跳轉到微博受權頁面。微博登陸按鈕的連接形以下方的 URL：

 https://api.weibo.com/oauth2/authorize?client_id=123050457758183&redirect_uri=http://jianshu.com/callback

　　URL 中要包含如下參數：

• client_id：在微博開放平臺申請的應用 ID
• redirect_uri：受權成功後要跳轉到的地址

 　　點擊以上連接後跳轉到微博的受權頁面以下圖：

　　這個頁面會告訴用戶第三方應用要獲取用戶的哪些數據，以及擁有什麼權限，好比在上圖中簡書會要求得到我的信息、好友關係、分享內容到微博以及得到評論的權限，用戶點擊「容許」則表示容許簡書得到這些數據，進行下一步。

　　2.頁面自動跳轉到初始參數中redirect_uri 定義的那個URL，並自動在 URL 末尾添加一個 code 參數，實際跳轉的地址形如:

http://jianshu.com/callback?code=2559200ecd7ea433f067a2cf67d6ce6c

　　3.第三步，簡書經過上一步獲取的 code 參數換取 Token，Token 就是前文中說到的鑰匙。簡書請求以下的接口獲取 Token：

　　POST https://api.weibo.com/oauth2/access_token
　　要包含如下參數：

• client_id：在微博開放平臺申請的應用 ID
• client_secret：在微博開放平臺申請時提供的APP Secret
• grant_type：須要填寫authorization_code
• code：上一步得到的 code
• redirect_uri：回調地址，須要與註冊應用裏的回調地址以及第一步的 redirect_uri 參數一致

　注：獲取token十分重要，採用POST方式比較安全。

 

　4.經過第三步的請求，接口返回 Token 和相關數據：

{
 "access_token": "ACCESS_TOKEN",//Token 的值
 "expires_in": 1234,//過時時間
 "uid":"12341234"//當前受權用戶的UID。
}

　　5.在第四步中獲取了access_token ，使用它，就能夠去獲取用戶的資源了，要獲取用戶暱稱和頭像，請求以下接口：

　　GET https://api.weibo.com/2/users/show.json

　　攜帶參數：

• access_token：上一步獲取的access_token
• uid：用戶的帳號 id，上一步的接口有返回

　　注：access_token使用時間有限，若失效，經常使用的解決方法：

• 從新受權登陸
• 使用refresh_token，從新申請。（通常用在不間斷連續在線）

 

　　6.最後一步，微博返回用戶信息，簡書進行處理，整個流程結束。

　　經過以上的方式，在簡書和新浪微博中間創建了一個獨立的權限層，這個權限由用戶賦予，能夠被用戶隨時取消，不一樣第三方應用之間相互獨立，互不干擾，這樣就完全解決了明文存放帳號密碼的問題。

 

 總結：

　　目前不少互聯網公司都提供了本身的開放平臺使第三方應用接入。開源項目中也有不少框架提供了OAuth的實現，例如Spring Security OAuth，Apache Oltu等。使用OAuth協議可以很好的保證第三方應用訪問用戶數據的安全性。

 

參考文獻：

　　https://www.jianshu.com/p/0db71eb445c8

　　http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html