在日常使用各個APP的時候，大家應(yīng)該都或多或少接觸過與“授權(quán)”有關(guān)的場景。大家有沒有想過在不需要輸入密碼賬號的情況下，是怎么實現(xiàn)第三方登錄的呢？本文作者將結(jié)合自己的項目經(jīng)歷來跟大家談?wù)勊赖氖跈?quán)登錄。

談到授權(quán)登錄，相信大家并不陌生，在日常使用各個APP的時候，大家應(yīng)該都或多或少接觸過與“授權(quán)”有關(guān)的場景，比如：進入支付寶或微信中某個子應(yīng)用時會出現(xiàn)的彈窗，這些都屬于授權(quán)登錄的范疇。在支付寶和微信所包含服務(wù)越來越多的情況下，這個功能給我們帶來了極大的便利。

但不知道大家有沒有想過，這種看似很正常、方便、簡單的功能，是怎么做到在我不輸入任何賬戶密碼信息的情況下實現(xiàn)第三方服務(wù)賬戶登錄的，而且在登錄之后里面的購物車、訂單記錄還都全部同步了。而且在第一次授權(quán)成功之后，后面的登錄都是直接完成的。

是因為微信或者支付寶拿到并保存了我們的賬號密碼么？那這個算信息泄露么？

本文我將就自己的項目經(jīng)歷來談一談我所知道的授權(quán)登錄。

一、名稱解釋：什么是授權(quán)登錄？

授權(quán)登錄是指通過一套簡單、安全的交互流程，讓第三方應(yīng)用可以在不知道用戶登錄名和密碼的情況下，獲取到用戶的的對應(yīng)信息，從而實現(xiàn)在第三方應(yīng)用中的對應(yīng)客戶端的登錄并關(guān)聯(lián)第三方平臺賬戶。

也就是說，對于用戶來說，當你登錄了一個APP之后，你再使用這個APP上的任何第三方服務(wù)，都不需要再手動輸入一遍第三方服務(wù)對應(yīng)的賬號密碼。而且在完成第一次登陸后，接下來的一段時間內(nèi)用戶再使用此服務(wù)都可以實現(xiàn)無感知登錄。

二、需求背景：為什么要做授權(quán)登錄？

（1）縮短用戶操作步驟，降低流失率

手動輸入賬號密碼如果作為常規(guī)的登錄方式，那么在阻斷用戶操作流程的同時，必然也會將一部分用戶趕走，故授權(quán)登錄降低了用戶的操作成本，更容易促進用戶轉(zhuǎn)化的前提。

（2）統(tǒng)一接入規(guī)范，把控登錄方式

因為各應(yīng)用的頁面是由第三方自己開發(fā)的，所以再風格樣式、提供服務(wù)等方面的差異，必然會導致各服務(wù)的登錄頁面也會存在著些許差異，例如：在同一個平臺上，有的應(yīng)用支持手機驗證碼登錄、有的支持郵箱登錄、有的甚至還支持其他平臺的賬號登錄（如：微信里面支持支付寶賬號快捷登錄），這其實是不利于整體品牌形象的營造和用戶體驗的統(tǒng)一的。

（3）獲取用戶信息，考慮合規(guī)要求

授權(quán)登錄在為用戶提供便利的同時還能獲取更多的信息（如：昵稱、頭像），并且授權(quán)彈窗上的用戶協(xié)議可以避免合規(guī)性風險。

（4）協(xié)議管理方便，快速簽約解約

同意授權(quán)登錄之后等于用戶跟平臺簽訂了一個允許獲取指定信息的協(xié)議，故授權(quán)登錄功能必然會帶來協(xié)議管理功能，通過此功能，用戶可以快速的注銷各服務(wù)的賬號。

三、前端業(yè)務(wù)流程：授權(quán)登錄相關(guān)的業(yè)務(wù)流程

1. 授權(quán)登錄流程

1. 用戶登錄客戶端，進入第三方應(yīng)用；
2. 點擊授權(quán)按鈕，客戶端喚起授權(quán)頁面；
3. 點擊“同意”授權(quán)按鈕，發(fā)起授權(quán)流程；
4. 授權(quán)成功，第三方應(yīng)用賬號登錄并關(guān)聯(lián)，進行后續(xù)流程；
5. 授權(quán)失敗，提示“系統(tǒng)繁忙”，退出子應(yīng)用；
6. 點擊“拒絕”按鈕，直接退出子應(yīng)用。

2. 查看用戶授權(quán)協(xié)議

1. 客戶端協(xié)議管理列表頁；
2. 授權(quán)登錄彈窗。

3. 解除協(xié)議流程

1. 用戶登錄客戶端，進入到協(xié)議管理列表頁；
2. 選中想要解約的協(xié)議，進入到協(xié)議詳情頁；
3. 點擊“解除”授權(quán)按鈕，發(fā)起協(xié)議解約；
4. 解約成功，提示“解約成功”，回到協(xié)議管理列表頁；
5. 解約失敗，提示“解約失敗”，回到協(xié)議管理列表頁。

四、關(guān)于后端業(yè)務(wù)流程：授權(quán)登錄相關(guān)后臺之間的交互

1. 簡單概括后端交互流程

1. 用戶進入第三方應(yīng)用后觸發(fā)了授權(quán)彈窗，用戶同意授權(quán)后，第三方頁面于是知道了它被允許獲取用戶的相關(guān)信息了；
2. 但這個信息第三方那里肯定沒有，而因為用戶已經(jīng)登錄過客戶端了，客戶端系統(tǒng)肯定存有，所以它需要去找客戶端要用戶信息；
3. 但在沒有經(jīng)過客戶端系統(tǒng)允許的情況下，第三方不可能直接和客戶端系統(tǒng)交流，因為中間隔著彈窗（客戶端前端），所以它先讓授權(quán)彈窗去告訴客戶端系統(tǒng)，說想聊一聊；
4. 于是彈窗就去告訴客戶端系統(tǒng)，說有人想聊一聊，客戶端系統(tǒng)判斷了下第三方是好人之后同意了，給出了通行證；
5. 有了這個通行證之后，雙方系統(tǒng)之間就可以進行交流了，也就可以拿到用戶的信息了，從而實現(xiàn)登錄和關(guān)聯(lián)賬戶。

2. 其中必要的參數(shù)

• code：可以看作第三方要發(fā)起授權(quán)所必須取得的通行證，有了這個通行證，雙方的服務(wù)層才能進行交互。當?shù)谌角岸苏{(diào)起授權(quán)彈窗時，由客戶端前端獲得后返回給第三方，第三方拿到code后，可以通過后端之間的交互去申請指令派access_token，有效期很短（可能短于5s）。
• access_token：俗稱指令牌，由客戶端服務(wù)端鑒權(quán)中心根據(jù)code和第三方應(yīng)用信息返回給第三方后端，有了指令牌，第三方就可以申請從客戶端服務(wù)器里獲得用戶信息了，有效期一般較短（如1個小時）。
• refresh_token：用以在access_token過期后，重新刷新指令牌的計時，有效期一般較長（如120天），超過有效期之后，整個授權(quán)登錄過程就要重新來一遍。
• openid：用戶的唯一標識，通過openid第三方可以從客戶端服務(wù)器拿到對應(yīng)用戶的賬戶信息，從而將其和自己本身的賬號進行關(guān)聯(lián)。

3. 幾種異常情況

1. 幾種必要參數(shù)過期或失效；
2. 用戶狀態(tài)異?！醋缘谌劫~號、風控黑名單等、登錄狀態(tài)異常、未簽約成功；
3. 商戶狀態(tài)異?！春灱s該產(chǎn)品、權(quán)限不足、第三方應(yīng)用校驗不合法；
4. 授權(quán)、查詢失??；
5. 系統(tǒng)服務(wù)超時或不穩(wěn)定。

五、部分產(chǎn)品相關(guān)的考慮

1. 數(shù)據(jù)指標——注意頁面埋點

1. 原登錄頁的用戶流失率，和授權(quán)彈窗拒絕按鈕的“點擊/pv”進行對比；
2. 原登錄頁和授權(quán)彈窗的頁面停留時長進行對比；
3. 購買轉(zhuǎn)化率的前后對比。

2. 產(chǎn)品體驗——部分細節(jié)

1. 拒絕授權(quán)增加二次確認彈窗，引導用戶同意授權(quán)，促進用戶的業(yè)務(wù)流程和購買轉(zhuǎn)化；
2. 用戶授權(quán)協(xié)議頁面增加客服渠道入口，便于有疑問的用戶進行咨詢；
3. 建議將授權(quán)流程后置，讓用戶可以先看到子應(yīng)用里面的營銷元素再進行彈窗授權(quán)，提高轉(zhuǎn)化；
4. 傳給商戶手機號，便于第三方新用戶進行注冊時省去輸入手機號這一步；
5. 所需授予權(quán)限內(nèi)容可以配置，便于其他應(yīng)用進行復用，如：頭像、昵稱、手機號、郵箱等。

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

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