首页 > 其他分享 >如何实现一套简单的oauth2授权码类型认证，一些思路，供参考

如何实现一套简单的oauth2授权码类型认证，一些思路，供参考

时间：2023-11-20 22:36:10浏览次数：28  
标签：code 121.46 10.80 认证 token oauth2 授权 供参考

背景

组内人不少，今年陆陆续续研发了不少系统，一般都会包括一个后台管理系统，现在问题是，每个管理系统都有RBAC那一套用户权限体系，实在是有点浪费人力，于是今年我们搞了个统一管理各个应用系统的RBAC的系统，叫做应用权限中心，大致就是：

  1. 各个应用在我们系统注册，并录入应用支持的各类权限（如菜单权限、数据权限、接口权限等）；
  2. 统一管理所有用户（包括公司员工、合作伙伴员工等）；
  3. 各个接入系统的管理员可以在自己的应用建立角色，赋予其某些权限；接下来，又可以给人员分配这些角色。

在以上数据维护完成后，就可以由我们系统提供oauth2认证这一套体系，oauth2简单理解，类似于平时那些网站的第三方渠道登录，比如，第一次去到一个陌生网站，不想注册用户、密码那些，此时，如果网站支持微信、qq、google、github等登录方式，就很方便，登录完成后，这个网站就已经知道我们是谁了，知道我们是谁之后，再来做权限也就简单了，还是RBAC那一套。

由于我们的应用权限中心管理了多个应用的权限，所以可以给某个人分配各个系统下的角色，这个人也就有了各个系统下的权限。

oauth2那一套，是在用户完成身份认证的基础下才能走完整个流程的，那就是说，已经知道这个用户是谁了，那就可以去应用权限中心获取这个人在里各个应用下有哪些角色，有哪些权限了。

oauth2的整体数据流

oauth2这个东西，流程图比较复杂，我就不从这方面去讲了，我先说下大体思路，然后直接给大家看我们系统的网络抓包数据，来了解整个数据流向吧。

我们这里涉及两个系统的交互，一个是类似于微信、qq、github这种的oauth2授权服务器，一个是需要接入到这些授权服务器的应用，如应用A，它的角色是oauth2客户端。

现在开发应用A，一般都是前后端分离，前端调用应用A后端接口，此时假设用户是没登录，后端接口判别到这种情况，给前端抛错误码，前端此时就再调用后端另一个接口，该接口会组装一个指向oauth2授权服务器的授权请求url，意思是前端需要到授权服务器那边去进行身份认证、授权等，前端拿到这个url，就跳转过去。

跳转过去后，oauth2服务器那边会检查用户在这边登录了没有，没登录的话，流程没法继续往下走，会先把这个授权请求给保存下来，然后让用户登录；用户登录成功后，再把之前保存的那个请求拿出来执行。

授权请求主要做的事情就是，检查参数是否合法，如这个第三方应用在自己这边注册了没，如果检查没问题，就会随机生成一个临时的code，拼接到第三方应用提供的回调url中，然后302重定向到第三方应用A。

第三方应用A需要拿着这个code，请求自己的后端，第三方应用的后端拿到code后，去通过后台http调用，调用授权服务器的根据code获取token的接口，拿到token后，返回给第三方应用A的前端。

后续，第三方应用的前端每次请求就带着这个token来请求后端，后端拿着token去请求授权服务器，获取这个token对应的用户信息，权限信息（如这个人在应用A中有哪些菜单权限等），进行权限控制。

技术选型

目前，要实现oauth2客户端的话，可以选择spring security，具体可以看官网文档。

要实现oauth2授权服务器的话，有如下选择：

spring-authorization-server

spring官方发布的第二代的授权服务项目，但目前使用的人较少，感觉也还不是很成熟。且因为还在使用java8，所以只能用0.4.x的版本，就更不成熟了。

https://spring.io/projects/spring-authorization-server#support

版本 Initial Release End of Support jdk 备注
1.1.x 2023-05-16 2024-05-16 java17 https://docs.spring.io/spring-authorization-server/docs/current/reference/html/getting-started.html
1.0.x 2022-11-21 2025-11-21 java17 https://docs.spring.io/spring-authorization-server/docs/1.0.3/reference/html/getting-started.html
0.4.x 2022-11-20 2025-11-21 Java 8 https://docs.spring.io/spring-authorization-server/docs/0.4.3/reference/html/getting-started.html

坐标：

https://mvnrepository.com/artifact/org.springframework.security/spring-security-oauth2-authorization-server

<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-oauth2-authorization-server</artifactId>
    <version>0.4.3</version>
</dependency>

image-20230727135633453

OAuth2 For Spring Security

https://mvnrepository.com/artifact/org.springframework.security.oauth/spring-security-oauth2

坐标：

<dependency>
    <groupId>org.springframework.security.oauth</groupId>
    <artifactId>spring-security-oauth2</artifactId>
    <version>2.5.2.RELEASE</version>
</dependency>

现状：

已经不再维护，最新版本2.5.2也还有多个cve漏洞，由于我们目前要求必须解决各种cve漏洞（一般靠版本升级解决，但这个已经是最新版本了没法升了）.

另外，其内部实现中使用了session+cookie机制，当时以为是有状态的，不支持集群部署，后来才知道也是支持用redis之类的（靠spring session项目）。

另外，前后端未分离，定制页面较为复杂

https://spring.io/blog/2022/06/01/spring-security-oauth-reaches-end-of-life

参考第二种实现的源码进行简单实现

最终没办法，第二种因为cve漏洞的问题，加上前后端不分离可能导致以后扩展困难（比如登录要支持多因素认证等，会比较头疼，还是做成前后端分离，交给专业前端比较好），最终决定第二种的源码进行修改。

实际的数据流

应用A：http://10.80.121.46:8086 前后端分离，后端接口都通过http://10.80.121.46:8086 nginx转发

授权服务器：http://10.80.121.46:8083 前后端分离，后端接口都通过http://10.80.121.46:8083 nginx转发

应用A检测到用户未登录

比如，我们这边的前端同事是这么判断：

const token = localStorage.getItem('token')
if (token == null) {
    window.location.href = "/v1/oAuth2Client/redirectToAuthorizeUrl";
}

我们以前的项目也有这样的：

if (response.status === 401) {
	window.location.href = "/oauth2/authorization/";
}

反正都是通过前端或后端知道用户没登录后，调用本应用的另一个接口。

应用A组装调用授权服务器的url

直接看下面报文，后端组装了一个指向授权服务器（http://10.80.121.46:8083）的授权接口（v1/oauth2/authorize）的url，还带了查询参数，client_id代表应用A自己，redirect_uri表示授权服务器回调自己的地址，response_type=code，表示使用oauth2的授权码流程

GET /v1/oAuth2Client/redirectToAuthorizeUrl HTTP/1.1
Host: 10.80.121.46:8086
Connection: keep-alive
...

HTTP/1.1 302 
Server: nginx/1.22.1
...
Location: http://10.80.121.46:8083/v1/oauth2/authorize?client_id=app-A&redirect_uri=http://10.80.121.46:8086/&response_type=code&scope=foo

注意，这里是直接后端返回了302，指示浏览器跳转到授权服务器，此时，如果有授权服务器这个domain下的cookie，是可以携带过去的；一般，我们都会在用户在授权服务器登录完成后，在授权服务器domain下写个cookie，避免每次都要登录。

授权服务器检测到用户未登录

第一次流程，用户浏览器肯定是没有授权服务器domain下的cookie的，此时，我们后端就会把用户302重定向到授权服务器这边的统一登录页面：

GET /v1/oauth2/authorize?client_id=app-A
&redirect_uri=http://10.80.121.46:8086/&response_type=code&scope=foo HTTP/1.1
Host: 10.80.121.46:8083
...

HTTP/1.1 302 
Server: nginx/1.22.1
*
Location: http://10.80.121.46:8083/#/oauth-login?appCode=app-A&originUrl=aHR0cDovLzEwLjgwLjEyMS40Njo4MDgzL2FwcC1hdXRob3JpdHktYWRtaW4vdjEvb2F1dGgyL2F1dGhvcml6ZT9jbGllbnRfaWQ9YXBwLWRldi1wbGF0Zm9ybS1hZG1pbiZyZWRpcmVjdF91cmk9aHR0cDovLzEwLjgwLjEyMS40Njo4MDg2LyZyZXNwb25zZV90eXBlPWNvZGUmc2NvcGU9Zm9v

这个认证接口的后端处理也简单，检测请求携带了标识用户已登录的cookie没有，没有的话，重定向到登录页。

登录页携带了一些参数，这里最主要的是originUrl，这是因为，后端做的无状态，在完成登录请求后，还需要继续请求原始接口：

/v1/oauth2/authorize?client_id=app-A
&redirect_uri=http://10.80.121.46:8086/&response_type=code&scope=foo

所以，我这边选择把原始接口base64编码后，传给前端，由前端在完成登录后再次发起调用。

另外，这个登录页，大概下面这样：

http://10.80.121.46:8083/#/oauth-login

image-20231120214146058

登录

POST /v1/oauth2/oAuth2Login HTTP/1.1
Host: 10.80.121.46:8083
Connection: keep-alive
...

{"username":"admin","password":"f80e247e3ead3dd1f3a708b7ce4dcf54"}

这边不重要的参数就省了，就是用户名密码那些，还包括验证码啥的。

响应：

HTTP/1.1 200 
...
Access-Control-Allow-Methods: GET, POST, PUT, OPTIONS
Access-Control-Allow-Origin: http://10.80.121.46:8083
Access-Control-Allow-Credentials: true
Set-Cookie: SSO-JSESSIONID=f09b9e61d4114a058cd6f9b6b9ce85d7; Path=/; Domain=10.80.121.46; Max-Age=43200; Expires=Tue, 21 Nov 2023 01:11:42 GMT

登录逻辑：生成个随机数（token），然后作为key，用户信息为value，存redis，然后再就是把token写到domain下，写个cookie；

这块必须用cookie，因为浏览器在从应用A跳过来的时候，只有cookie才能带的过来，我们才知道用户是登录了没的。

前端在收到登录成功的code后，就把上一步的originUrl解码，然后重新发起调用：

/v1/oauth2/authorize?client_id=app-A
&redirect_uri=http://10.80.121.46:8086/&response_type=code&scope=foo

授权接口逻辑

主要就是各种参数校验，如client_id是否在授权服务器注册，各个参数的值是否合法，这块可以参考spring的代码实现。

一切没问题的话，就是生成个随机code，然后把code作为key，其他各种用户信息、认证请求的相关信息为value，存储到redis，然后就可以跳转回应用A了。

跳到应用A的什么地址呢，我们授权请求不是传了个redirect_uri吗，就重定向到哪里，只是会给你拼个code在后面

GET /?code=eEg7t5 HTTP/1.1
Host: 10.80.121.46:8086
...

携带code跳转回应用A

GET /?code=eEg7t5 HTTP/1.1
Host: 10.80.121.46:8086

我这边是跳转回应用A的前端的，前端拿到code，调用应用A的后端接口：利用code去请求授权服务器，获取token。

应用A前端调用后端接口，code换token

POST /v1/oAuth2Client/fetchAccessTokenByAuthorizeCode HTTP/1.1
Host: 10.80.121.46:8086
...

{"code":"eEg7t5"}

HTTP/1.1 200 
...

{"code":"0","message":"success","data":{"scope":"all","access_token":"eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjQ3NDAsInVzZXJuYW1lIjoiYWRtaW4iLCJleHRlbmQiOm51bGwsImV4cCI6MTcwMDU3MjMwM30.HxH99Z3Mz4IZfHlC_Ai1th7jURlNs5qsHSMpiQdtGgXDqX8_XNx9GxswB","token_type":"bearer","refresh_token":null,"expires_in":86400}}

后端就是拿着code，去请求授权服务器，拿到了token，我这边是直接把token给了前端存储。

后续的请求，前端都会携带token，后端判断token是否有效即可（大家肯定不希望每次都去授权服务器校验token，所以可以第一次的时候，拿token去授权服务器验证是否有效，并缓存结果；我这边更暴力，因为都是组内的系统，直接弄的jwt token，且token没加密）

根据token获取用户信息

前端拿着token去调用应用A后端接口，获取用户信息；

POST /v1/oAuth2Client/queryUserInfo HTTP/1.1
Host: 10.80.121.46:8086
Connection: keep-alive
Content-Length: 0
AccessToken: eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjQ3NDAsInVzZXJuYW1lIjoiYWRtaW4iLCJleHRlbmQiOm51bGwsImV4cCI6MTcwMDU3MjMwM30.HxH99Z3Mz4IZfHlC_Ai1th7jURlNs5qsHSMpiQdtGgXDqX8_XNx9G

HTTP/1.1 200 
...

{"code":"0","message":"请求成功","data":{"id":4740,"username":"admin","departmentName":null,"status":0,"statusName":"正常","roleListInfo":[]}}

用户信息都有了，获取权限信息也是一样的，这里不展示了。

简单的技术总结

我这边自己实现，是没办法，开源的没能满足自己要求，其实还有一点，我们那个用户名是可能重复的，就是说，在统一登录页，输入用户名，可能在后台查到多个用户，只能加上另一个内部的隐性字段才能不重，这也是我们必须自研的原因。我实现的比较简单，不是一个圆的轮子，仅供大家参考（一些异常场景，由于对oauth2的认识也不是特别深，只能以后慢慢完善了）

大家如果自研授权服务器，肯定涉及在授权服务器域名下写cookie，此时注意，后端接口都通过前端的nginx去转，会减少很多跨域相关的问题，信我的没错，我都踩过了。

另外，有时候后端直接重定向有问题时，就可以将要重定向的地址给到前端，由前端去window.location.href跳转也是ok的，也会减少一些跨域问题。

有问题可以留言，谢谢大家。

参考

https://www.cnblogs.com/cjsblog/p/10548022.html

https://mp.weixin.qq.com/s/AW3zkzIYR6kbQVbPlQmpMA 写cookie遇到问题时参考本篇

https://www.springcloud.io/post/2022-04/spring-samesite/

https://www.ituring.com.cn/article/200275

标签：code,121.46,10.80,认证,token,oauth2,授权,供参考
From： https://www.cnblogs.com/grey-wolf/p/17845054.html

相关文章

  • SpringBoot集成LDAP认证登录
    Maven依赖<?xmlversion="1.0"encoding="UTF-8"?><projectxmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.......
  • 2023第四季北京/杭州/青岛/深圳DAMA-CDGA/CDGP认证备考
    DAMA认证为数据管理专业人士提供职业目标晋升规划，彰显了职业发展里程碑及发展阶梯定义，帮助数据管理从业人士获得企业数字化转型战略下的必备职业能力，促进开展工作实践应用及实际问题解决，形成企业所需的新数字经济下的核心职业竞争能力。DAMA是数据管理方面的认证，帮助数据从业者提升......
  • 2023第四季北京/杭州/青岛/深圳CDGP认证报名到这儿
    DAMA认证为数据管理专业人士提供职业目标晋升规划，彰显了职业发展里程碑及发展阶梯定义，帮助数据管理从业人士获得企业数字化转型战略下的必备职业能力，促进开展工作实践应用及实际问题解决，形成企业所需的新数字经济下的核心职业竞争能力。DAMA是数据管理方面的认证，帮助数据从业者提升......
  • 华为设备_AAA认证
    拓扑图配置/验证1.本地AAA认证、授权，缺省域（telnet）AR1telnetAR2配置sysnameAR1#interfaceGigabitEthernet0/0/0ipaddress10.1.12.1255.255.255.0#sysnameAR2#aaalocal-userhciepasswordcipherhuawei@123local-userhcieprivilegelevel3local-userhci......
  • 史上功能最全的Java权限认证框架！
    大家好，我是Java陈序员。权限认证是我们日常开发绕不过的话题，这是因为我们的应用程序需要防护，防止被窜入和攻击。在Java后端开发中，实现权限认证有很多种方案可以选择，一个拦截器、过滤器也许就可以轻松搞定。当然，现在也有很多成熟的框架，供我们选择。轻量的Shiro,Spring家族的......
  • 【第6章】认证技术原理与应用（信息安全工程师）
    6.1.1认证概念认证是一个实体向另外一个实体证明其所声称的身份的过程。在认证过程中，需要被证实的实体是声称者，负责检查确认声称者的实体是验证者。认证一般由标识(Identification)和鉴别(Authentication)两部分组成。标识是用来代表实体对象（如人员、设备、数据、服务、应......
  • OAuth2
    参考：265Stuff：OAuth2.0SimpleExample周志明：《凤凰架构-架构安全性-授权-OAuth2》Google：OpenIDConnect 为了对OAuth2有一个直观的认识。我们先从一个例子开始。谷歌的OpenIdConnect是OAuth2的一个实践，集成了谷歌OpenIdConnect的网站，可以实现用谷歌账号登录它......
  • Lumen框架 之api用户认证
    一、配置1、在\app\bootstrap\app.php中取消注释$app->withFacades();$app->withEloquent();$app->routeMiddleware(['auth'=>App\Http\Middleware\Authenticate::class]);$app->register(App\Providers\AuthServiceProvider::class);2、创建用户......
  • netty tls单向认证通讯
    需求背景项目主要分为监管侧和企业侧，企业侧实时上传数据到云端，云端汇聚业务数据，上传过程需要保证传输的安全性。技术实现数据上传考虑到用HTTPS或者是TCP+TLS传输。其实使用HTTPS传输协议是比较简单的，但是项目硬件使用的4G无线网卡，而且需要实时检测设备运行状态，所以使用......
  • 第六章 消息认证和哈希函数 —— 现代密码学（杨波）课后题答案解析
    第五章作业参考答案1．6.1.3节的数据认证算法是由CBC模式的DES定义的，其中初始向量取为0，试说明使用CFB模式也可获得相同的结果。解：设需认证的数据分为64比特长的分组，D1,D2,…,DN，其中DN不够64比特则右边补0，由题设，数据认证算法相当于在CBC模式中初始向量取为0，并按如下关系进行：   ......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99