在日常使用各个APP的时候，大家应该都或多或少接触过与“授权”有关的场景。大家有没有想过在不需要输入密码账号的情况下，是怎么实现第三方登录的呢？本文作者将结合自己的项目经历来跟大家谈谈他所知道的授权登录。

谈到授权登录，相信大家并不陌生，在日常使用各个APP的时候，大家应该都或多或少接触过与“授权”有关的场景，比如：进入支付宝或微信中某个子应用时会出现的弹窗，这些都属于授权登录的范畴。在支付宝和微信所包含服务越来越多的情况下，这个功能给我们带来了极大的便利。

但不知道大家有没有想过，这种看似很正常、方便、简单的功能，是怎么做到在我不输入任何账户密码信息的情况下实现第三方服务账户登录的，而且在登录之后里面的购物车、订单记录还都全部同步了。而且在第一次授权成功之后，后面的登录都是直接完成的。

是因为微信或者支付宝拿到并保存了我们的账号密码么？那这个算信息泄露么？

本文我将就自己的项目经历来谈一谈我所知道的授权登录。

一、名称解释：什么是授权登录？

授权登录是指通过一套简单、安全的交互流程，让第三方应用可以在不知道用户登录名和密码的情况下，获取到用户的的对应信息，从而实现在第三方应用中的对应客户端的登录并关联第三方平台账户。

也就是说，对于用户来说，当你登录了一个APP之后，你再使用这个APP上的任何第三方服务，都不需要再手动输入一遍第三方服务对应的账号密码。而且在完成第一次登陆后，接下来的一段时间内用户再使用此服务都可以实现无感知登录。

二、需求背景：为什么要做授权登录？

（1）缩短用户操作步骤，降低流失率

手动输入账号密码如果作为常规的登录方式，那么在阻断用户操作流程的同时，必然也会将一部分用户赶走，故授权登录降低了用户的操作成本，更容易促进用户转化的前提。

（2）统一接入规范，把控登录方式

因为各应用的页面是由第三方自己开发的，所以再风格样式、提供服务等方面的差异，必然会导致各服务的登录页面也会存在着些许差异，例如：在同一个平台上，有的应用支持手机验证码登录、有的支持邮箱登录、有的甚至还支持其他平台的账号登录（如：微信里面支持支付宝账号快捷登录），这其实是不利于整体品牌形象的营造和用户体验的统一的。

（3）获取用户信息，考虑合规要求

授权登录在为用户提供便利的同时还能获取更多的信息（如：昵称、头像），并且授权弹窗上的用户协议可以避免合规性风险。

（4）协议管理方便，快速签约解约

同意授权登录之后等于用户跟平台签订了一个允许获取指定信息的协议，故授权登录功能必然会带来协议管理功能，通过此功能，用户可以快速的注销各服务的账号。

三、前端业务流程：授权登录相关的业务流程

1. 授权登录流程

1. 用户登录客户端，进入第三方应用；
2. 点击授权按钮，客户端唤起授权页面；
3. 点击“同意”授权按钮，发起授权流程；
4. 授权成功，第三方应用账号登录并关联，进行后续流程；
5. 授权失败，提示“系统繁忙”，退出子应用；
6. 点击“拒绝”按钮，直接退出子应用。

2. 查看用户授权协议

1. 客户端协议管理列表页；
2. 授权登录弹窗。

3. 解除协议流程

1. 用户登录客户端，进入到协议管理列表页；
2. 选中想要解约的协议，进入到协议详情页；
3. 点击“解除”授权按钮，发起协议解约；
4. 解约成功，提示“解约成功”，回到协议管理列表页；
5. 解约失败，提示“解约失败”，回到协议管理列表页。

四、关于后端业务流程：授权登录相关后台之间的交互

1. 简单概括后端交互流程

1. 用户进入第三方应用后触发了授权弹窗，用户同意授权后，第三方页面于是知道了它被允许获取用户的相关信息了；
2. 但这个信息第三方那里肯定没有，而因为用户已经登录过客户端了，客户端系统肯定存有，所以它需要去找客户端要用户信息；
3. 但在没有经过客户端系统允许的情况下，第三方不可能直接和客户端系统交流，因为中间隔着弹窗（客户端前端），所以它先让授权弹窗去告诉客户端系统，说想聊一聊；
4. 于是弹窗就去告诉客户端系统，说有人想聊一聊，客户端系统判断了下第三方是好人之后同意了，给出了通行证；
5. 有了这个通行证之后，双方系统之间就可以进行交流了，也就可以拿到用户的信息了，从而实现登录和关联账户。

2. 其中必要的参数

• code：可以看作第三方要发起授权所必须取得的通行证，有了这个通行证，双方的服务层才能进行交互。当第三方前端调起授权弹窗时，由客户端前端获得后返回给第三方，第三方拿到code后，可以通过后端之间的交互去申请指令派access_token，有效期很短（可能短于5s）。
• access_token：俗称指令牌，由客户端服务端鉴权中心根据code和第三方应用信息返回给第三方后端，有了指令牌，第三方就可以申请从客户端服务器里获得用户信息了，有效期一般较短（如1个小时）。
• refresh_token：用以在access_token过期后，重新刷新指令牌的计时，有效期一般较长（如120天），超过有效期之后，整个授权登录过程就要重新来一遍。
• openid：用户的唯一标识，通过openid第三方可以从客户端服务器拿到对应用户的账户信息，从而将其和自己本身的账号进行关联。

3. 几种异常情况

1. 几种必要参数过期或失效；
2. 用户状态异常——未注册第三方账号、风控黑名单等、登录状态异常、未签约成功；
3. 商户状态异常——未签约该产品、权限不足、第三方应用校验不合法；
4. 授权、查询失败；
5. 系统服务超时或不稳定。

五、部分产品相关的考虑

1. 数据指标——注意页面埋点

1. 原登录页的用户流失率，和授权弹窗拒绝按钮的“点击/pv”进行对比；
2. 原登录页和授权弹窗的页面停留时长进行对比；
3. 购买转化率的前后对比。

2. 产品体验——部分细节

1. 拒绝授权增加二次确认弹窗，引导用户同意授权，促进用户的业务流程和购买转化；
2. 用户授权协议页面增加客服渠道入口，便于有疑问的用户进行咨询；
3. 建议将授权流程后置，让用户可以先看到子应用里面的营销元素再进行弹窗授权，提高转化；
4. 传给商户手机号，便于第三方新用户进行注册时省去输入手机号这一步；
5. 所需授予权限内容可以配置，便于其他应用进行复用，如：头像、昵称、手机号、邮箱等。

本文由 @月半小阁 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Pexels，基于 CC0 协议