本文通俗易懂地剖析用戶授權(quán)的設(shè)計原理和四種授權(quán)模式，重點介紹授權(quán)碼登錄模式，適合閱讀的人群：開放平臺/第三方合作的產(chǎn)品經(jīng)理，初入職場的產(chǎn)品經(jīng)理。

1. 應(yīng)用場景

我們每個人都遇到過授權(quán)登錄的環(huán)節(jié)，授權(quán)登錄的應(yīng)用無孔不入，可能你是在授權(quán)應(yīng)用權(quán)限，或是授權(quán)賬戶登錄，或是授權(quán)個人信息。

我們常見的應(yīng)用場景一般有以下：

• 新安裝應(yīng)用：授權(quán)獲取存儲空間，設(shè)備信息等（手機原生彈窗）
• 支付寶授權(quán)登錄淘寶：授權(quán)使用支付賬戶登錄淘寶APP（淘寶原生頁面）
• 微信打開美團外賣：授權(quán)獲取你的頭像和地理位置（微信原生彈窗）

因而授權(quán)登錄是應(yīng)用間交互的重要且廣泛的步驟，深入了解過其中的原理很有必要。

2. 授權(quán)登錄是什么？

以美團外賣授權(quán)獲取你的頭像和地理位置為例：

• 頭像和地理位置屬于你的個人信息，如需要傳輸，必須經(jīng)得本人的同意，法律不允許默認傳輸。
• 授權(quán)登錄是經(jīng)得資源所有者（亦即是用戶）同意，服務(wù)提供商（亦即是微信，他為你提供授權(quán)服務(wù)）提供授權(quán)服務(wù)和應(yīng)用方（他來使用你的授權(quán)）使用授權(quán)的過程。

字面意思就是如下圖流程：

值得關(guān)注的是第3步和第4步：當(dāng)你在授權(quán)的過程中，實則是你和微信的直接交互，與美團外賣小程序無關(guān)。

亦即是：你是跟微信同意授權(quán)，也是微信接收到你的“同意”的指令，即使在網(wǎng)站用微信登錄也是如此，如豆瓣登錄，需要微信掃描二維碼，確保授權(quán)動作保留和發(fā)生在微信自己的環(huán)境內(nèi)。

3. 授權(quán)登錄的模式

那么從形式來說，授權(quán)登錄可以分為靜默授權(quán)和手動授權(quán)兩種模式：

• 靜默授權(quán)：一般是用于獲取一些類似于用戶ID的信息，比如每個用戶在微信的ID被稱為openid，這種ID只是用戶的唯一身份認證（相當(dāng)于編號），不包含個人信息，應(yīng)用獲取openid并不能分析出你的手機號和身份證號這些個人信息。顯然，很多用戶都不知道openid是什么，總不能彈個彈窗問用戶“你是否同意傳輸openid”吧。因而這類傳輸，用戶是無感的，用戶只需訪問了某個頁面，后臺會向微信請求拿到你的openid。
• 手動授權(quán)：這種亦即是我們上文提到的用戶場景，這類型場景需要獲取的信息是你的個人信息，比如頭像，昵稱，手機號和地址等等。這些個人信息是必須經(jīng)過用戶手動點擊同意的。

4. OAuth2原理及剖析

以上第2點是授權(quán)的基本簡化，本節(jié)是更重點介紹OAuth2的系統(tǒng)鏈路流程（無論是靜默或是手動，系統(tǒng)鏈路一致，只是形式的區(qū)分）。目前市面上涉及授權(quán)，權(quán)限申請的業(yè)務(wù)均通過OAuth2的方法進行設(shè)計。

OAuth2具體可以分為以下四種：

1. 授權(quán)碼模式（authorization code）【重點】
2. 簡化模式（implicit）
3. 密碼模式（resource owner password credentials）
4. 客戶端模式（client credentials）

4.1 授權(quán)碼模式

其中最重要的就是第一種授權(quán)碼模式，接下來我以企業(yè)微信授權(quán)碼方法做解析，其流程圖非常清晰。

例子講解：

場景：該身份授權(quán)是用戶在企業(yè)微信使用第三方應(yīng)用時拉起授權(quán)頁面的流程。類似于你在微信打開餓了么小程序。

系統(tǒng)交互的步驟：

1. 用戶在企業(yè)微信打開一個A應(yīng)用。此時A應(yīng)用通過靜默推送獲取到用戶的userid，發(fā)現(xiàn)這個用戶沒有頭像和昵稱信息在A應(yīng)用的數(shù)據(jù)庫。
2. 此時，A應(yīng)用調(diào)用企業(yè)微信的OAuth認證鏈接，這個鏈接要帶上企業(yè)ID（表明應(yīng)用方），權(quán)限獲取范圍（頭像+昵稱），標(biāo)記本次授權(quán)的編號（state）和授權(quán)完跳轉(zhuǎn)的地址，做好鏈接之后，向微信發(fā)送過去。
3. 企業(yè)微信收到請求后，校驗企業(yè)ID和授權(quán)跳轉(zhuǎn)的地址是否對應(yīng)。如果驗證通過，企業(yè)微信會給A應(yīng)用一個令牌（code），并在前端打開企業(yè)微信的授權(quán)頁面（該頁面由企業(yè)微信管理）。
4. 用戶點擊授權(quán)了之后，企業(yè)微信可以利用code和state向企業(yè)微信請求用戶信息API，獲得用戶token，最終獲得指定用戶信息。
5. 同時用戶點擊授權(quán)后，企業(yè)微信關(guān)閉授權(quán)頁，并跳轉(zhuǎn)到A應(yīng)用在第2步提供的跳轉(zhuǎn)地址。

4.2 簡化模式

請記住第一個模式中的第（1）步和第（2）步都需要A應(yīng)用處理，簡化模式就是簡化了第（2）步。

以下在微信的場景僅用于舉例：

1. 用戶點擊應(yīng)用入口之后，微信直接讓用戶是否同意授權(quán)（授權(quán)的內(nèi)容和觸發(fā)時間提前配置好），用戶點擊同意。
2. 用戶同意后，跳轉(zhuǎn)到該應(yīng)用在后臺預(yù)留的地址，并且微信把訪問令牌直接告訴應(yīng)用。
3. 應(yīng)用利用訪問令牌找微信獲取用戶信息，完成。

此處你有沒有發(fā)現(xiàn)，前面授權(quán)的過程并不需要應(yīng)用本身參與，這個就是比授權(quán)碼模式簡化的地方。但這種模式不支持用戶令牌的更新，也就是用戶第一次授權(quán)過期了之后，下一次又需要重新手動授權(quán)。

4.3 密碼模式

這種模式很直接，相當(dāng)于你把你微信的賬戶密碼告訴餓了么，餓了么利用你的賬戶密碼去獲取信息。這種方式極其不安全，用戶的賬戶信息隨時會被外泄。

4.4 客戶端模式

這種其實不屬于授權(quán)，實則就是兩個應(yīng)用間直接進行信息傳輸，與用戶無關(guān)。

5. 總結(jié)

1. 授權(quán)分為靜默授權(quán)和手動授權(quán)，一般出現(xiàn)在打開應(yīng)用登錄的環(huán)節(jié)，應(yīng)用廣泛。
2. 授權(quán)的組件或頁面必須在擁有數(shù)據(jù)的應(yīng)用中，這樣才能確保用戶在授權(quán)頁上同意協(xié)議，清晰看到傳輸?shù)臄?shù)據(jù)范圍，以及確保用戶親手同意授權(quán)。
3. 授權(quán)分為四個模式，其中授權(quán)碼模式是應(yīng)用最廣泛，最重要的模式。
4. 授權(quán)碼模式亦即是A應(yīng)用拼接企業(yè)參數(shù)向企業(yè)微信請求打開授權(quán)頁面，獲取用戶授權(quán)碼code，再利用code獲得用戶的token，最終獲取用戶信息。

相關(guān)閱讀

API接口入門（一）：讀懂API接口文檔

API接口入門（一）：讀懂API接口文檔

作者：就是愛睡覺，電商和金融業(yè)行業(yè)的產(chǎn)品，以TO B業(yè)務(wù)為主，文章是用于記錄自己在產(chǎn)品工作的思考和想法，希望有想法的小伙伴共同交流。

本文由 @就是愛睡覺 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議