传送门

再次重申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协议时，都基本有一个准备工作，即要先进行注册。

下一节，会结合阿里云开放平台，看一下注册流程如何操作及背后的设计

Oauth2系列2：授权码模式相关推荐

andpods授权码订单号分享_不要再让你的接口裸奔了，Boot快速尝试OAuth2密码和授权码模式...
微服务火热,前后端分离,oauth2 是我们接口调用认证的首选.springboot 天然集成 oauth2,使用非常方便,简单记录下,尝尝鲜. 一.啥是OAuth2 OAuth(开放授权)是一个开放 ...
Oauth2.0认证---授权码模式
目录: 1.功能描述 2.客户端的授权模式 3.授权模式认证流程 4.代码实现 1.功能描述 OAuth在"客户端"与"服务提供商"之间,设置了一个授权层(au ...
html页面授权码,spring boot 2.0 整合 oauth2 authorization code授权码模式
oauth2 authorization code 大致流程用户打开客户端后,客户端要求用户给予授权. 用户同意给予客户端授权. 客户端使用授权得到的code,向认证服务器申请token令牌. 认证 ...
Spring Security Oauth2 (二) 代码授权码模式
└─java└─claroja│ Springsecurityoauth2DemoApplication.java│├─config│ AuthorizationServerConfig.java│ ...
OAuth2.0授权码模式原理与实战
OAuth2.0是目前比较流行的一种开源授权协议,可以用来授权第三方应用,允许在不将用户名和密码提供给第三方应用的情况下获取一定的用户资源,目前很多网站或APP基于微信或QQ的第三方登录方式都是基于O ...
前后端分离Oauth2.0 - springsecurity + spring-authorization-server —授权码模式
序言对于目前有很多的公司在对旧的web工程做重构,拆分服务,使用前端vue,后端springboot微服务,重构的要点之一是认证授权框架的选型. 对于原有的 spring-security-oaut ...
java 授权码模式_Spring Security OAuth2 授权码模式的实现
写在前边在文章OAuth 2.0 概念及授权流程梳理中我们谈到OAuth 2.0的概念与流程,这里我准备分别记一记这几种授权模式的demo,一方面为自己的最近的学习做个总结,另一方面做下知识输出, ...
OAuth2.0授权码模式实战
OAuth2.0是目前比较流行的一种开源授权协议,可以用来授权第三方应用,允许在不将用户名和密码提供给第三方应用的情况下获取一定的用户资源,目前很多网站或APP基于微信或QQ的第三方登录方式都是基于O ...
java调用授权接口oauth2_微信授权就是这个原理，Spring Cloud OAuth2 授权码模式
上一篇文章Spring Cloud OAuth2 实现单点登录介绍了使用 password 模式进行身份认证和单点登录.本篇介绍 Spring Cloud OAuth2 的另外一种授权模式-授权码模式 ...

Oauth2系列2：授权码模式

传送门

再次重申oauth2的定义

定义

作用

标准授权码流程

4个参与角色

资源拥有者

客户端

授权服务

受保护资源

授权码流程

引导授权

获取code

用授权码code换取令牌token

返回令牌格式

令牌续期

预告

Oauth2系列2：授权码模式相关推荐

最新文章

热门文章