SpringSecurity中OAuth2.1/OIDC1.0升级变化明细

spring-oauth-server v3.0.0版本中,我们全部升级了OAuth协议(从OAuth2.0升级到OAuth2.1)并同步增加了对OIDC1.0的支持落地。这些实现的底层依赖SpringSecurity框架的变化,此文将这些细节一一通过对比来讲解。

每一项是一个变化点,依次罗列出之前,之后(v3.0.0)以及说明。

  • spring security oauth组件

spring-security-oauth2 v2.3.x

spring-security-oauth2-authorization-server v1.1.x

Spring Security官方对旧的不再维护支持而推荐升级替换用新的实现,详见 https://andaily.com/blog/?p=20077

  • grant_type变化
  • authorization_code (包括PKCE)
  • password
  • client_credentials
  • implicit
  • refresh_token
  • authorization_code (包括PKCE)
  • client_credentials
  • refresh_token
  • device_code (urn:ietf:params:oauth:grant-type:device_code)
  • jwt-bearer (urn:ietf:params:oauth:grant-type:jwt-bearer)

grant_type的变化看到安全在不断升级,同时为更好的支持物联网提供协议上的支撑。具体说明详见 https://andaily.com/blog/?p=103

  • scope变化
  • read
  • write
  • trust
  • openid
  • profile
  • email
  • address
  • phone

scope的变化按照OIDC协议的规范来实现的,代码中详见 OidcScopes.java

  • MySQL表结构
  • oauth_client_details
  • oauth_client_token
  • oauth_access_token
  • oauth_refresh_token
  • oauth_code
  • oauth2_registered_client
  • oauth2_authorization
  • oauth2_authorization_consent

表设计变化挺大的,主要由于框架的实现重新设计与实现,新的表结构能更好地满足token全生命周期管控(同时带来一定的性能问题,可通过技术手段解决),有更好的配置项扩展能力(通过将各类配置项通过JSON格式数据存储)

  • token配置项
  • access_token_validity -设置token有效时长(默认12小时)
  • refresh_token_validity -设置refresh_token有效时长(默认30天)
  • authorization_code_time_to_live -设置authorization_code有效时长(默认5分钟)
  • access_token_time_to_live -设置access_token有效时长(默认5分钟)
  • access_token_format -设置access_token的格式,有两选项self-contained(自签即JWT格式,默认) reference(兼容旧的,通过UUID生成随机值)
  • device_code_time_to_live -设置device_code有效时长(默认5分钟)
  • reuse_refresh_token -设置是否复用refresh_token值当刷新token后(默认true复用,设置false时每次刷新后将生成新的refresh_token值)
  • refresh_token_time_to_live -设置refresh_token有效时长(默认60分钟)
  • idtoken_signature_algorithm -设置生成id_token使用的签名算法(默认RS256)

新版本与token配置项相关的请查看 TokenSettings.java 类与数据库表oauth2_registered_client 中的字段 token_settings

  • client配置项
  • trusted -是否授权信任; 适用于grant_type=”authorization_code”的情况,当用户登录成功后,若该值为0,则会跳转到让用户Approve的页面让用户同意授权
  • autoapprove -是否自动跳过用户授权步骤
  • client_secret_expires_at -client_secret过期时间,可设置
  • client_authentication_methods -认证请求时传递client_secret支持的方式(如post, basic)
  • post_logout_redirect_uris -退出时的重定向到client的uri地址
  • require_proof_key -是否强制使用PKCE(默认false)
  • require_authorization_consent -授权时是否要求用户进行确认(默认false)
  • token_endpoint_authentication_signing_algorithm -指定jwt-bearer流程中生成id_token时使用的签名算法(常见如RS256, ES256)
  • client_name -可以给client设置一个有业务意义的名称

新版本与client配置项相关的请查看 ClientSettings.java 类与数据库表 oauth2_registered_client 中的字段 client_settings

  • java版本

java 8

java 17+(openJDK)

从JVM层面做安全升级,同时提升性能与稳定性

  • token全生命周期管控API
  • /oauth/token -通过认证生成token
  • /oauth/check_token -检查token状态
  • /oauth/error -响应HTML异常信息
  • /oauth2/token -通过认证生成token
  • /userinfo -获取用户信息,OIDC协议中定义
  • /oauth2/revoke -吊销已签发的token
  • /oauth2/introspect -审查token状态(包括是否存活等)
  • /connect/logout -退出并销毁token,浏览器上调用

新版本的token全生命周期管控完整性更好,也是协议更新版本的优势所在

通过各明细对比,能更清晰理解与把控各项安全细节。

oauth2-shiro 2.0.0版本发布,安全大升级

oauth2-shiro v2.0.0版本正式发布,在距上一次发布7年后,更新了大版本,对安全漏洞等问题进行大升级。

该版本主要更新内容:

  1. 升级使用springboot,调整工程结构,打包由war换成jar,使用thymeleaf替换servlet/jsp;spring大版本升级到5.3提升安全性。
  2. JDK由1.7升级到1.8,日志框架使用logback替换log4j(处理掉log4j安全漏洞)。
  3. 升级shiro版本到v1.11.0,解决相应的shiro版本漏洞。
  4. 密码存储算法由MD5替换为SHA-256,并支持盐(salt),让密码存储更安全可靠(通过配置参数authz.store.credentials.alg来控制与向下兼容)。
  5. OAuth token支持使用JWT格式(通过配置参数authz.token.generator.type来控制与向下兼容)。
  6. 对初始的账户密码与client secret使用更加安全的密码策略:包括大小写字母,数字与特殊符号,长度至少10位。

v2.0.0版本链接:https://gitee.com/mkk/oauth2-shiro/tree/2.0.0/

【推荐升级】

读《聊聊‘架构’》— 尚不够架构

内容摘录:

  • 业务和架构,是压在软件从业人员身上的两座大山。页软件从业人员手上却只有一个武器:技术。可是这个武器还时灵时不灵,
  • 业务和架构都是处理人的问题。而技术人员最讨厌处理的就是人的问题,心里面厌恶,却又无法逃避。
  • 架构的目的并非产生一个业务之外新的东西出来,只是为了让业务长得更加高大强壮,服务于更多的人。
  • 做架构的人必须亲自体验业务,感受业务,才可能真正认识业务的个性,真正认识业务所面临的问题。
  • 识别问题这个能力基本上就决定了架构师的水平。
  • 识别了问题的主体,自然而然地就附带了这么多的隐含信息。挖掘出隐含信息,就自然而然能够问出来其他问题了,
  • 架构切分实际就是对利益相关人的利益进行切分或合并,使得每个利益相关人的权责是对等的,每个利益相关人可以为自己的利益负责。
  • 架构切分的最终结果都会体现在组织架构上,只有这样才能够让架构落地并推进。
  • 一个好的架构拆分,会形成一棵树,慢慢会长成一片森林。
  • 架构的目的就是为了增长。
  • 架构师有权力的同时也有其义务,也是权责对等的。架构师要时时把增长放在自己的第一考虑要素,把识别核心生命周期及其主体作为第一思考,这样才能确保权力的合理分配,保证增长的效率。这是真正的架构师和普通人思考的区别。
  • 要知道,工作是否完成由业务人员决定,而不是软件工程师自己。
  • 随着对业务的熟悉,对时间的恐惧才会慢慢地消失。对业务领域理解得越深入,就越知道如何去发现问题,慢慢就成为业务专家了。
  • 形象一点说,业务是硬币,架构和技术是硬币的两面。
  • 要知道开源的只是代码而已,而代码并非软件生命周期的核心。
  • 软件生命周期的核心是代码的运行生命周期和用户访问生命周期,而不是代码的建立生命周期。
  • 很多软件工程师学了大量的算法和计算机基础,然而在工作中发现派不上用场。这是非常正常的,因为这些内容是为了在科学领域做研究准备的。而在业务领域,大多是如何把现有的业务在软件中模拟出来的问题,并没有太多高深的数学问题。
  • 软件的拆分必须要和业务的拆分对应起来,
  • 很多人总是拆不好的原因,就是忽视了业务生命周期的分析。因为软件的核心是模拟业务,而业务代码又是按照业务的生命周期组织的,
  • 大数据其实说的是新的针对大量数据的处理技术,并非“大数据”这个概念表面文字那样是说“数据”本身。
  • 数据库事务只应该存在于和数据库打交道的存储代码中。

 

推荐你去品一品此书。

20210110221948