目录
传送门
再次重申oauth2的定义
定义
作用
标准授权码流程
4个参与角色
资源拥有者
客户端
授权服务
受保护资源
授权码流程
引导授权
获取code
用授权码code换取令牌token
返回令牌格式
令牌续期
预告
传送门
Oauth2系列1:初识Oauth2
在前面一节,对oauth2有了一个初步概念。这里重点讨论下授权码模式
再次重申oauth2的定义
定义
前面对oauth2的定义有过百科的引用,英文好的也可以看看官方定义:OAuth 2.0。这里不是要对定义做过多理解,而是重点放在下面的场景下的讨论中
作用
oauth2通常是用来做第三方应用授权的,比如前面的微信例子:网站应用微信登录开发指南
多读几遍上面的一句话,会不会发现有一些矛盾?
oauth2不是用来做授权吗,为什么微信用它来做第三方登录呢?带着这个疑问,再次回顾一下下面这个微信登录时序图
再看一下微信官方给出的步骤解释
1. 第三方发起微信授权登录请求,微信用户允许授权第三方应用后,微信会拉起应用或重定向到第三方网站,并且带上授权临时票据 code 参数;2. 通过 code 参数加上 AppID 和AppSecret等,通过 API 换取access_token;3. 通过access_token进行接口调用,获取用户基本数据资源或帮助用户实现基本操作。
通过上面的时序图,及步骤解释,都提到了”微信用户“,就是说要应用微信登录第三方应用,前提是用户必须是微信用户!
这个要求也是顺理成章的,用户都不是微信的,微信怎么对用户主体做属性授权呢?
但是需要思考一个问题,对于第三方网站来说,如果是微信用户,并且依赖微信的开放平台做了授权登录,那么对应三方应用来说,它自己到底存不存储用户相关信息呢?如果没有自己的用户信息,如果网站需要自己的权限管理,该怎么办?
微信授权登录,三方应用能获取的信息是有限的,可能只有用户相关的一点可怜的用户昵称,性别,头像等。其它一些信息,需要依赖开放平台的支持,这多少也有些受制于人!
所以,我个人觉得,对于三方网站的不同定位,如果需要自己做一些权限管控,或者是后续基于用户维度的功能,是需要有一套自己的账户体系的,只不过在用户使用方式止,可以做成是高阶功能再认证或补全身份信息的流程。此时的流程,大致如下
这个流程跟微信标准相比,就是加了后面几个步骤(第7步之后),主要就是第三方应用的账户处理
- 当用户通过微信oauth2协议登录成功之后,会拿到access_token,这个时候可以通过token获取用户授权的信息
- 拿到授权信息之后,可以采用生成临时游客账号的方式,将用户的vx_id与当前用户的临时游客账号绑定起来
- 这样,后续如果用户还是通过微信授权登录,也在第三方系统有了自己的账号,只不过这一步用户可能(也不一定需要感知)没有感知
- 等到用户要用到系统的高阶功能,比如一些增值服务,要付费或者实名认证这种,再让用户来补全身份信息或者进行实名认证
标准授权码流程
4个参与角色
上面我们看到微信第三方授权登录的时序图,一共有3个参与方:用户,第三方应用,vx开放平台。
其实严格意义来讲,标准的oauth2协议,总共有4个角色
资源拥有者
就是拥有资源的主体,在上面的登录场景中就是指微信用户,所有的用户信息都是属于他的。当然,资源不一定是只有用户信息,也可能是任何能授权的数据(一切皆数据)。通常拥有者都是一个人,这个人才拥有数据
客户端
客户端,在上面的登录场景中就是指第三方应用,是需要申请资源权限的第三方应用
授权服务
授权服务就是对资源进行授权的系统,在上面的登录场景中就是指微信开放平台。在上面,大部分的核心逻辑都是在它在负责处理的:第三方应用身份检验,授权管理(生成授权页面,权限列表检验),生成授权码code及返回授权码code给第三方应用等,以及最终的令牌颁发等
受保护资源
受保护资源就是指可以用来授权的信息或数据,上面的登录场景中就是指用户的信息,比如姓名,性别,头像等
但是在微信登录的场景中,只有三个角色,并没有把受保护资源单独列出。因为微信开放平台本身就拥有用户的信息,所以是可以视为一体的。
但是在有些场景,受保护资源有可能是单独服务,是可以跟授权服务分开的。比如,在一些微服务架构中,授权服务有可能是放到网关来做的,而资源是在业务服务中的
授权码流程
OAuth 诞生之初就是为了解决 Web 浏览器场景下的授权问题,上面第三方微信登录,有可能是发生在PC端的浏览器,也有可能是移动端的APP应用上,而移动端的APP应用其实也可以视为一种浏览器。
而通常现在的客户端,一般是有前端界面与后端应用的,前端一般也是让用户在浏览器上面操作。
现在假设是在浏览器的场景下,一般授权码流程到底是怎么样的呢?来看一个更细致的流程
引导授权
正常来说,第三方业务系统都有自己的会话管理,就像在前面提到的传统session会话
对于java开发的系统,一般常用的会有server的过滤器Filter,通过session来判断用户会话是否过期,过期会引导用到登录界面进行登录认证。
对于ouath2这种协议作微信第三方登录认证,也是需要业务系统做会话管理的。就是用户第一次访问业务系统时,如果发现用户是未登录,则调用认证服务的接口,这个接口最终会生授权登录界面,让用户授权
第一步:请求CODE
第三方使用网站应用授权登录前请注意已获取相应网页授权作用域(scope=snsapi_login),则可以通过在 PC 端打开以下链接: https://open.weixin.qq.com/connect/qrconnect?appid=APPID&redirect_uri=REDIRECT_URI&response_type=code&scope=SCOPE&state=STATE#wechat_redirect 若提示“该链接无法访问”,请检查参数是否填写错误,如redirect_uri的域名与审核时填写的授权域名不一致或 scope 不为snsapi_login。
当第三方系统请求这个接口时,微信会跳转到微信的一个标准授权界面。这就是时序图中的第一次重定向。这里要特别说明的是,业务系统一般也是通过重定向的方式请求这个接口的。可以前端js或者后端跳转:
- 前端:window.location.href=’请求code的接口’;
- 后端:response.sendRedirect(“请求code的接口”);
而其中的参数也是有讲究的
参数说明
参数 | 是否必须 | 说明 |
---|---|---|
appid | 是 | 应用唯一标识 |
redirect_uri | 是 | 请使用 urlEncode 对链接进行处理 |
response_type | 是 | 填code |
scope | 是 | 应用授权作用域,拥有多个作用域用逗号(,)分隔,网页应用目前仅填写snsapi_login |
state | 否 | 用于保持请求和回调的状态,授权请求后原样带回给第三方。该参数可用于防止 csrf 攻击(跨站请求伪造攻击),建议第三方带上该参数,可设置为简单的随机数加 session 进行校验 |
lang | 否 | 界面语言,支持cn(中文简体)与en(英文),默认为cn |
- appid是应用的唯一标识,即要接入oauth2做授权登录,必须要先在微信开放平台进行注册,这一部分属于准备工作,会放到下一节里面介绍
- redirect_uri是在注册的填入的回调地址,也属于准备工作,会放到下一节里面介绍。这个地址,主要是用于微信开放平台生成授权码之后,会通过重定向的方式跳转到这个地址,所以必须跟业务系统一致
获取code
用户允许授权后,将会重定向到redirect_uri的网址上,并且带上 code 和state参数
redirect_uri?code=CODE&state=STATE
- 所以上面配置的redirect_uri相当重要,理论上它就是第三方业务系统里面的一个接口,用来接收微信回传的code,而state是防csrf攻击的参数,业务系统可以通过它判断是否是自己发出的请求,如果不是,则可以拒绝此次访问
用授权码code换取令牌token
通过 code 获取access_token
https://api.weixin.qq.com/sns/oauth2/access_token?appid=APPID&secret=SECRET&code=CODE&grant_type=authorization_code
如果第三方业务系统拿到授权码code,这个时候就可以通过code换取令牌了。如果令牌获取成功,就表示用户认证完成,可以登录了
注意,这个接口严格来说,必须是后端发起调用,因为这里面的参数除了appid之外,还需要secret参数,这个参数是不能暴露到浏览器的。
1、Appsecret 是应用接口使用密钥,泄漏后将可能导致应用数据泄漏、应用的用户数据泄漏等高风险后果;存储在客户端,极有可能被恶意窃取(如反编译获取Appsecret);2、access_token 为用户授权第三方应用发起接口调用的凭证(相当于用户登录态),存储在客户端,可能出现恶意获取access_token 后导致的用户数据泄漏、用户微信相关接口功能被恶意发起等行为;3、refresh_token 为用户授权第三方应用的长效凭证,仅用于刷新access_token,但泄漏后相当于access_token 泄漏,风险同上。建议将secret、用户数据(如access_token)放在 App 云端服务器,由云端中转接口调用请求。
参数说明
参数 | 是否必须 | 说明 |
---|---|---|
appid | 是 | 应用唯一标识,在微信开放平台提交应用审核通过后获得 |
secret | 是 | 应用密钥AppSecret,在微信开放平台提交应用审核通过后获得 |
code | 是 | 填写第一步获取的 code 参数 |
grant_type | 是 | 填authorization_code |
- appid同上,后续会详细说明如何产生及设计
- secret是应用的密钥,理论上不能暴露出去的,它跟appid是一一对应的
- grant_type是授权码类型,这里默认定authorization_code,表示授权码类型。顾名思义,还有其它类型,后面会讨论其它类型
返回令牌格式
最后,看一下,返回令牌的格式
返回说明
正确的返回:
{ "access_token":"ACCESS_TOKEN", "expires_in":7200, "refresh_token":"REFRESH_TOKEN","openid":"OPENID", "scope":"SCOPE","unionid": "o6_bmasdasdsad6_2sgVt7hMZOPfL"}
在这里,会发现,除了刚才讨论的访问令牌access_token之外,还多了其它几个参数
参数 | 说明 |
---|---|
access_token | 接口调用凭证 |
expires_in | access_token接口调用凭证超时时间,单位(秒) |
refresh_token | 用户刷新access_token |
openid | 授权用户唯一标识 |
scope | 用户授权的作用域,使用逗号(,)分隔 |
unionid | 当且仅当该网站应用已获得该用户的 userinfo 授权时,才会出现该字段。 |
- 其中,openid,跟unionid并不是oauth2协议的标准字段,而是不同开放平台单独的设计
- 而refresh_token,如果场景中不涉及续期这种,也可以不用到它。但是对于很多应用,尤其是APP端来说,用户基本都是长效登录,就是用户登录之后,可能一个月都是在线的,不需要重复登录,这时候就是极需要刷新令牌的
令牌续期
access_token是调用授权关系接口的调用凭证,由于access_token有效期(目前为2个小时)较短,当access_token超时后,可以使用refresh_token进行刷新,access_token刷新结果有两种:
1. 若access_token已超时,那么进行refresh_token会获取一个新的access_token,新的超时时间;2. 若access_token未超时,那么进行refresh_token不会改变access_token,但超时时间会刷新,相当于续期access_token。
refresh_token拥有较长的有效期(30天),当refresh_token失效的后,需要用户重新授权。
请求方法
获取第一步的 code 后,请求以下链接进行refresh_token:
https://api.weixin.qq.com/sns/oauth2/refresh_token?appid=APPID&grant_type=refresh_token&refresh_token=REFRESH_TOKEN
参数说明
参数 | 是否必须 | 说明 |
---|---|---|
appid | 是 | 应用唯一标识 |
grant_type | 是 | 填refresh_token |
refresh_token | 是 | 填写通过access_token获取到的refresh_token参数 |
- 可以看到在刷新令牌这里,grant_type填的是refresh_token;而在上面获取token接口,填入的是authorization_code。
- 这刷新令牌接口调用成功之后,对于访问令牌的处理,其它有不同的实现,有的开放平台是一定会生成一个新的access_token,有的会对它做续期,直到达到刷新令牌的生命周期。甚至有的平台会,生成一个新的刷新令牌。这个没有统一的做法,取决于不同的实现
预告
这一节主要讨论了授权码流程,但是各大开放平台,在使用第三方登录的oauth2协议时,都基本有一个准备工作,即要先进行注册。
下一节,会结合阿里云开放平台,看一下注册流程如何操作及背后的设计