API接口入門(三):用戶授權(quán)流程原理
本文通俗易懂地剖析用戶授權(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具體可以分為以下四種:
- 授權(quán)碼模式(authorization code)【重點】
- 簡化模式(implicit)
- 密碼模式(resource owner password credentials)
- 客戶端模式(client credentials)
4.1 授權(quán)碼模式
其中最重要的就是第一種授權(quán)碼模式,接下來我以企業(yè)微信授權(quán)碼方法做解析,其流程圖非常清晰。
例子講解:
場景:該身份授權(quán)是用戶在企業(yè)微信使用第三方應(yīng)用時拉起授權(quán)頁面的流程。類似于你在微信打開餓了么小程序。
系統(tǒng)交互的步驟:
- 用戶在企業(yè)微信打開一個A應(yīng)用。此時A應(yīng)用通過靜默推送獲取到用戶的userid,發(fā)現(xiàn)這個用戶沒有頭像和昵稱信息在A應(yīng)用的數(shù)據(jù)庫。
- 此時,A應(yīng)用調(diào)用企業(yè)微信的OAuth認證鏈接,這個鏈接要帶上企業(yè)ID(表明應(yīng)用方),權(quán)限獲取范圍(頭像+昵稱),標(biāo)記本次授權(quán)的編號(state)和授權(quán)完跳轉(zhuǎn)的地址,做好鏈接之后,向微信發(fā)送過去。
- 企業(yè)微信收到請求后,校驗企業(yè)ID和授權(quán)跳轉(zhuǎn)的地址是否對應(yīng)。如果驗證通過,企業(yè)微信會給A應(yīng)用一個令牌(code),并在前端打開企業(yè)微信的授權(quán)頁面(該頁面由企業(yè)微信管理)。
- 用戶點擊授權(quán)了之后,企業(yè)微信可以利用code和state向企業(yè)微信請求用戶信息API,獲得用戶token,最終獲得指定用戶信息。
- 同時用戶點擊授權(quán)后,企業(yè)微信關(guān)閉授權(quán)頁,并跳轉(zhuǎn)到A應(yīng)用在第2步提供的跳轉(zhuǎn)地址。
4.2 簡化模式
請記住第一個模式中的第(1)步和第(2)步都需要A應(yīng)用處理,簡化模式就是簡化了第(2)步。
以下在微信的場景僅用于舉例:
- 用戶點擊應(yīng)用入口之后,微信直接讓用戶是否同意授權(quán)(授權(quán)的內(nèi)容和觸發(fā)時間提前配置好),用戶點擊同意。
- 用戶同意后,跳轉(zhuǎn)到該應(yīng)用在后臺預(yù)留的地址,并且微信把訪問令牌直接告訴應(yīng)用。
- 應(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é)
- 授權(quán)分為靜默授權(quán)和手動授權(quán),一般出現(xiàn)在打開應(yīng)用登錄的環(huán)節(jié),應(yīng)用廣泛。
- 授權(quán)的組件或頁面必須在擁有數(shù)據(jù)的應(yīng)用中,這樣才能確保用戶在授權(quán)頁上同意協(xié)議,清晰看到傳輸?shù)臄?shù)據(jù)范圍,以及確保用戶親手同意授權(quán)。
- 授權(quán)分為四個模式,其中授權(quán)碼模式是應(yīng)用最廣泛,最重要的模式。
- 授權(quán)碼模式亦即是A應(yīng)用拼接企業(yè)參數(shù)向企業(yè)微信請求打開授權(quán)頁面,獲取用戶授權(quán)碼code,再利用code獲得用戶的token,最終獲取用戶信息。
相關(guān)閱讀
作者:就是愛睡覺,電商和金融業(yè)行業(yè)的產(chǎn)品,以TO B業(yè)務(wù)為主,文章是用于記錄自己在產(chǎn)品工作的思考和想法,希望有想法的小伙伴共同交流。
本文由 @就是愛睡覺 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議
API接口入門系列三篇文章寫的好棒,小白從中學(xué)到了很多,感謝作者的分享
寫的真好,后面這部分我的腦袋開始不夠用了
感謝精彩的分享
太厲害了,我也是產(chǎn)品經(jīng)理,但對技術(shù)知之甚少,有推薦的課程嗎?
感恩分享
非常棒,不懂技術(shù)的也能看懂
這樣的文章真好,易懂
感覺像是技術(shù)人員研究的東西啊
坐等更新
通俗易懂,這些都是作者自己在工作中自己研究的嗎,佩服佩服
點個贊,寫得不錯,對于我這樣的小白也比較好懂!
沒得人評論呢