[OAuth2.0三方登录系列文章-1]OAuth2.0与三方登录的端到端方案

系列文章

[OAuth2.0三方登录系列文章-1]OAuth2.0与三方登录的端到端方案
[OAuth2.0三方登录系列文章-2]如何设计基于OAuth2.0的授权登录SDK以及竞品分析
[OAuth2.0三方登录系列文章-3]如何设计一个与微信相同的分享sdk

序章

通过此文章您将了解以下几方面内容

1. 为什么会有OAuth 2.0
2. OAuth 2.0是什么
3. OAuth 2.0 可以用来做什么
4. OAuth 2.0 有几种方式可以实现
5. 作为OAuth 2.0的提供方, 需要提供哪些内容
6. 作为OAuth 2.0的接入方, 需要做哪些事情

以App开发举例, 我们一般会有两种用户的注册登录方式

1. App自身的注册登录, 以下我们称之为一方注册登录
2. App对接三方渠道的注册登录, 以下称之为三方注册登录

以下会先介绍一方登录, 逐步引出三方登录

1. 背景

1.1 一方注册登录

常用的一方登录的业务诉求, 国内常见的是, (手机号+密码)/(手机号+验证码), 在海外比较常见的是(邮箱+密码)/(邮箱+验证码).

无论是那种产品交互形式, 一般来讲, 是要涉及到将用户的信息,注册到服务器, 这样才可以保持用户的信息, 保存到云端. 到此也就不可避免的要提到端到端的解决方案, 即我们通常说的客户端与服务端跨端的技术解决方案. 常见的做法如下:

通过accessToken + refreshToken的方式实现的.

accessToken作为业务服务交互的令牌. 即每次客户端的请求, 都需要携带此参数.
refreshToken用于置换有效的accessToken.仅仅与用户域/用户模块进行交互

客户端跟服务端的注册以及后续的操作一般是遵循方面的操作流程.

1. App携带着用户的个人信息, 请求server进行注册
2. server各种校验(如用户是否已经存在, 用户是否需要风控)通过后, 最终返回给App用户的accessToken + refreshToken
3. app登录后, 将accessToken和refreshToken进行保存; 用户在app中的所有后续网络操作, 需要携带accessToken(如用户访问自己的购物车, 查看个人的操作历史记录)
4. server会校验token的有效性, 然后返回给app有效的接口请求信息
5. 用户再次进行app中的操作, 需要访问网络时(accessToken过期)
6. server再次校验accessToken的有效性, 结果发现accessToken过期, 因而会告知用户, token无效了
7. app此时, 携带者用户的freshToken请求用户域的server, 再次置换新的有效的accessToken.
8. server 返回新的有效的accessToken和可选的refreshToken.
9. app此时收到新的token后, 便可以继续前面的第6步骤的网络请求.

作为一方的注册登录可以采用这种方式, 而对于使用三方注册登录呢?

1.2 三方注册登录

三方注册登录不同于一方:

1. 站在使用三方登录的app(以下称之为使用者App)的角度. 希望对接三方注册登录流程尽可能的简单.
2. 站在三方登录提供者的app(以下称之为提供者App)的角度, 希望此注册登录是安全的, 并且是能够让用户得到信息输出的确认.
3. 站在提供者App的用户的角度, 希望自己的信息得到最大程度的保证, 而不是信息被泄漏.

而传统模式(客户端-服务端), 直接在后端给于三方应用授权凭证, 会带来以下的几类问题.

1. 三方应用需要存储 资源服务服务端的授权凭证, 需要密码, 并且密码是明文.
2. 服务端需要支持密码的认证.
3. 三方应用会获取到资源拥有者的被保护的资源. 资源拥有者对于资源的管控不充足.
4. 资源拥有着, 取消三方个体的访问授权是比较困难的, 除非更改这个三方个体的密码.
5. 任何与第三方应用程序的妥协都会 资源服务器在终端用户的密码以及受该密码保护的所有数据之间妥协。

通俗案例 快递员送货的问题

因而OAuth2.0应运而生.

2. 什么是OAuth 2.0

RFC官方文档

OAuth 2.0 授权框架使 三方应用程序获取对 HTTP 服务的有限访问，无论是在通过审批交互 代表资源所有者在资源所有者和 HTTP 服务之间，或通过允许第三方应用程序以自己的名义获取访问权限。

2.1 Who

官方doc

1. resource owner 资源拥有者: 能够授予对受保护资源的访问权限的实体。 当资源所有者是一个人时，它被称为 最终用户
2. resource server 资源服务器: 持有资源, 通过访问的token 可以接受和响应 受保护的资源.
3. client : 代表应用程序发出受保护资源请求的应用程序 资源所有者及其授权。术语“客户”确实 不暗示任何特定的实现特征（例如， 应用程序是否在服务器、桌面或其他 设备）
4. authorization server 认证服务器: 在成功向资源服务器认证, 并且获得了授权后, 服务器用于向client颁发访问的token.

案例, 用户 使用 Keep 的App 要采用 微信 登录授权.

资源拥有者, 是 终端用户.
资源服务器, 是 微信的服务器.
client, 是 Keep
认证服务器, 是微信的认证服务器.

E.G.
即Keep App的用户(此用户拥有微信的账号), 他作为自己微信账户的资源拥有者, Keep作为client, 通过向微信的认证服务器发送验证并且通过后, 可以在client上, 获取到该用户微信 资源服务器上的账户信息.

2.2 How

2.2.1 官方介绍

官方介绍

操作步骤:

1. client 向 资源拥有者请求授权. 这个请求可以直接指向资源拥有者(如图所示), 或者更加倾向将此授权请求发送给授权服务器.
2. client 收到授权的凭证. (此凭证代表了资源拥有者的授权, 采用四种定义的授权方式或者采用拓展的类型). 这授权的类型 依赖于client 请求授权的类型, 以及 授权服务器支持的类型.
3. client通过授权服务器的认证和授权已经授予的信息, 请求授权的token.
4. 授权服务器认证client, 并且校验授权的信息, 如果有效, 颁发accessToken
5. client 通通过提供accessToken向授权服务器请求受保护的资源.
6. 资源服务器校验accessToken, 如果有效, 给于有效响应.

client 向资源拥有者 获取授权许可的推荐方式是, 采用授权服务器(authorization server)作为中介.

2.2.2 实际案例

2.2 授权许可

"授权许可"是代表着资源拥有者(resource owner)的授权(可以访问其受保护的资源)凭证, 用于client获取accessToken.

这里定义了四种授权的模式 以及 定义了附加类型的机制用于保证可扩展性.

1. 授权码(Authorization Code)
2. 隐藏式(implict)
3. 密码式(resource owner password credentials)
4. 凭证式(client credentials)

2.2.1 四种"授权许可"模式

四种授权的模式

官方doc
通俗理解

1. 授权码(Authorization Code)

授权码是通过授权服务器作为client和资源服务器的中介获取到的.
授权码有以下的几个优点

1. 有能力对client认证
2. 将accessToken直接给到client, 不用将他传递给资源拥有者的user-agent和潜在的暴露风险.

案例1:
微信: 移动应用微信登录

图示:

通用的三方登录做法:
以下以三方注册登录为例

案例2: 淘宝授权

2. 隐藏式(implict)

token直给

隐藏式是授权码的简化版. 对于client是在浏览器中用脚本语言开发的.(一般用到没什么后端的场景).
在这种方式中, client直接会收到access token的信息, 而不是授权码.

当采用隐藏式颁发token时, 认证服务器不会认证端侧的信息. 在某些情况下, client是可以通过URI的redirection做校验的.accessToken 可能被暴露给资源拥有者或者其他带有资源拥有者的user-agent的信息.

由于这种方式较少了多次交互的步骤来再次获取access token, 因而这种方式提高了某些client的响应性和高效性.(比如 client是采用了基于web 开发的应用). 但是这种优点是建立在损失安全性基础上的.

Facebook + Google的案例

3. 密码式(resource owner password credentials)

当应用之间高度可信时, 资源拥有者可以将用户+密码的信息提供给资源的拥有者. 用于置换access token的信息. 这种方式适用于其他授权的方式不可用时, 才会采用的方式.

尽管这种授权方式是提供了client可以使用的用户名和密码, 但是这种授予也应该只是一次生效的, 并且是用来置换access token的. 这样才能消除client保存用户的授权信息的影响.

4. 凭证式(client credentials)

当授权的范围仅是受保护的资源是在client的控制下时, 或者受保护的资源之前是被授权服务器已经安排好的.

**适用场景: **

1. 没有前端的命令行应用

四种授权模式总结

2.2.2 Access Token

access token是访问受保护资源的凭证. access Token是颁发给client的授权. 这个字符串对于client来讲是不感知的. 并且这个Token 是有访问的范围和访问的时效性的.

2.2.3 Refresh Token

Refresh Token 是用来获取access token的凭证. 授权服务器将refresh token 颁发给client. 当access token 失效或者过期时, 或者需要额外的访问token 具有相同或更窄的范围(访问令牌可能有更短的 生命周期和比资源授权更少的权限 所有者), 才需要使用refresh token 获取到新的access token. (此方式不是必选的, 但是可以优化client的体验. )

refresh token 仅仅跟授权服务器交互. 不会用于跟资源服务器的交互.

3. OAuth 2.0的实践

3.1 生产者(OAuth 2.0 提供方)

1. 提供开放平台, 可以让三方进行注册, 敏感权限的在线申请和审核
2. 提供对接文档和SDK, 方便使用方对接
3. 提供api接口, 在token失效等场景, 使用方可以再次调用, 获取到新的token.

对于App的SDK的设计, 可以参考以下的几篇文章:

如何设计一个与微信相同的分享sdk

3.2 消费侧(OAuth 2.0 使用方)

1. 在提供方的开发平台侧, 注册app的信息 以及 权限申请等相关信息
2. 对接对方的SDK
3. SDK 使用

移动应用微信登录开发指南

更新提醒

欢迎关注个人微信公众号