api介面鑑權方案

2023-09-28 17:32:15

本文通俗易懂地剖析使用者授權的設計原理和四種授權模式，重點介紹授權碼登入模式，適合閱讀的人群：開放平臺/第三方合作的產品經理，初入職場的產品經理。

1. 應用場景

我們每個人都遇到過授權登入的環節，授權登入的應用無孔不入，可能你是在授權應用許可權，或是授權賬戶登入，或是授權個人資訊。

我們常見的應用場景一般有以下：

因而授權登入是應用間互動的重要且廣泛的步驟，深入瞭解過其中的原理很有必要。

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

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

值得關注的是第3步和第4步：當你在授權的過程中，實則是你和微信的直接互動，與美團外賣小程式無關。

亦即是：你是跟微信同意授權，也是微信接收到你的“同意”的指令，即使在網站用微信登入也是如此，如豆瓣登入，需要微信掃描二維碼，確保授權動作保留和發生在微信自己的環境內。

那麼從形式來說，授權登入可以分為靜默授權和手動授權兩種模式：

靜默授權：一般是用於獲取一些類似於使用者ID的資訊，比如每個使用者在微信的ID被稱為openid，這種ID只是使用者的唯一身份認證（相當於編號），不包含個人資訊，應用獲取openid並不能分析出你的手機號和身份證號這些個人資訊。顯然，很多使用者都不知道openid是什麼，總不能彈個彈窗問使用者“你是否同意傳輸openid”吧。因而這類傳輸，使用者是無感的，使用者只需訪問了某個頁面，後臺會向微信請求拿到你的openid。
手動授權：這種亦即是我們上文提到的使用者場景，這型別場景需要獲取的資訊是你的個人資訊，比如頭像，暱稱，手機號和地址等等。這些個人資訊是必須經過使用者手動點選同意的。

以上第2點是授權的基本簡化，本節是更重點介紹OAuth2的系統鏈路流程（無論是靜默或是手動，系統鏈路一致，只是形式的區分）。目前市面上涉及授權，許可權申請的業務均通過OAuth2的方法進行設計。

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

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

例子講解：

場景：該身份授權是使用者在企業微信使用第三方應用時拉起授權頁面的流程。類似於你在微信開啟餓了麼小程式。

系統互動的步驟：

使用者在企業微信開啟一個A應用。此時A應用通過靜默推送獲取到使用者的userid，發現這個使用者沒有頭像和暱稱資訊在A應用的資料庫。
此時，A應用呼叫企業微信的OAuth認證連結，這個連結要帶上企業ID（表明應用方），許可權獲取範圍（頭像暱稱），標記本次授權的編號（state）和授權完跳轉的地址，做好連結之後，向微信傳送過去。
企業微信收到請求後，校驗企業ID和授權跳轉的地址是否對應。如果驗證通過，企業微信會給A應用一個令牌（code），並在前端開啟企業微信的授權頁面（該頁面由企業微信管理）。
使用者點選授權了之後，企業微信可以利用code和state向企業微信請求使用者資訊API，獲得使用者token，最終獲得指定使用者資訊。
同時使用者點選授權後，企業微信關閉授權頁，並跳轉到A應用在第2步提供的跳轉地址。

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

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

此處你有沒有發現，前面授權的過程並不需要應用本身參與，這個就是比授權碼模式簡化的地方。但這種模式不支援使用者令牌的更新，也就是使用者第一次授權過期了之後，下一次又需要重新手動授權。

這種模式很直接，相當於你把你微信的賬戶密碼告訴餓了麼，餓了麼利用你的賬戶密碼去獲取資訊。這種方式極其不安全，使用者的賬戶資訊隨時會被外洩。

這種其實不屬於授權，實則就是兩個應用間直接進行資訊傳輸，與使用者無關。