Spring Security OAuth过期后怎么解决？很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。
大家在选择 OAuth3 依赖的时候，可能也会困惑，有好几个地方都可以选：
那么到底选择哪一个依赖合适呢？这不同的依赖又有什么区别？今天松哥就来和大家聊一聊 Spring Security 中关于 OAuth3 的恩怨。
前言
先来大致介绍一下 OAuth3 在 Spring 框架中的发展历程。
大约十年前，Spring 引入了一个社区驱动的开源项目 Spring Security OAuth，并将其纳入 Spring 项目组合中。到今天，它已经发展成为一个成熟的项目，可以支持大部分 OAuth 规范，包括资源服务器、客户端和授权服务器等。
现在它已成为 UAA（User Account and Authentication Server） 的基础。Spring Security OAuth 项目已成为一个样板项目，它证明了 Spring 社区可以出色的完成工作。
然而早期的项目存在这样一些问题：
基于以上这些原因，官方决定在社区成功的基础上，重写 Spring Security OAuth，以更好地协调 Spring 和 OAuth，并简化代码库，以使 Spring 的 OAuth 支持更加灵活。
然而，在重写的过程中，发生了不少波折。
2018.01.30
事情得从 2018 年 1 月 30 号讲起。
那天 Spring 官方发了一个通知，说是要逐渐停止现有的 OAuth3 支持，而在 Spring Security5 中构建下一代 OAuth3.0 支持。
为什么要这样呢？
大家知道，OAuth3 只是一种协议，Spring 框架通过代码对这种协议进行落地。
当时 OAuth3 的落地方案比较混乱（这种混乱到今天依然存在），在 Spring Security OAuth、Spring Cloud Security、Spring Boot 1.5.x 以及当时最新的 Spring Security5.x 中都提供了对 OAuth3 的实现。
以至于当开发者需要使用 OAuth3 时，不得不问，到底选哪一个依赖合适呢？已经有三个地方提供了 OAuth3 的支持，已经够混乱了，为什么还要在最新的 Spring Security5.x 中继续提供实现呢？
太乱了！
所以 Spring 官方决定有必要将 OAuth3.0 的支持统一到一个项目中，以便为用户提供明确的选择并避免任何潜在的混乱，同时 OAuth3 的开发文档也要重新编写，以方便开发人员学习。所有的决定将在 Spring Security5 中开始，构建下一代 OAuth3.0 的支持。
从那个时候起，Spring Security OAuth 项目就正式处于维护模式。官方将提供至少 1 年的错误/安全修复程序，并且会考虑添加次要功能，但不会添加主要功能。同时将 Spring Security OAuth 中的所有功能重构到 Spring Security5.x 中。
老实说，这是一个英明的决定，当时并没有引起太多的反响。但是接下来的事情就不是那么顺利了。
2019.11.14
时间到了 2019.11.14。
这天，官方又发了个通知。
先说了 Spring Security OAuth 在迁往 Spring Security5.x 的过程非常顺利，大部分迁移工作已经完成了，剩下的将在 5.3 版本中完成迁移，在迁移的过程中还添加了许多新功能，包括对 OpenID Connect1.0 的支持
接下来话锋一转，说了一件很多人难以接受的事情，那就是将不再提供对授权服务器的支持（要是小伙伴们不懂什么是授权服务器，可以在公众号江南一点雨后台回复 OAuth3 ，有松哥写的 OAuth3 教程）。
不提供的原因，官方给了两个：
在 2019 年，将有大量的商业和开源授权服务器可用。授权服务器是使用一个库来构建产品，而 Spring Security 作为框架，并不适合做这件事情。
一石激起千层浪，许多开发者表示对此难以接受。这件事也在 Spring 社区引发了激烈的讨论，好在 Spring 官方愿意倾听来自社区的声音。
2020.04.15
这天，官方又发了个通知。
这次宣布了 Spring Authorization Server 项目。这是一个由 Spring Security 团队领导的社区驱动的项目，致力于向 Spring 社区提供 Authorization Server 支持。
官方倾听了来自社区的声音，决定继续提供授权服务器。
这次只是宣布了一下，算是安抚了一下社区的情绪，但是项目还没开发出来。
2020.08.21
Spring Authorization Server 0.0.1 正式发布！
同时公布了项目源码地址：https://github.com/spring-projects-experimental/spring-authorization-server
在这个版本中，主要提供了如下功能：
其他功能还在紧锣密鼓的开发中。
这就是 OAuth3 最近几年的变更之路。
回到问题
回到最开始的问题。
类过期了怎么办？
类过期是因为旧的写法已经不被支持，松哥举个简单例子，以前我们定义资源服务器是这样的：
@Configuration
@EnableResourceServer
public class ResourceServerConfig extends ResourceServerConfigurerAdapter {
@Bean
RemoteTokenServices tokenServices() {
RemoteTokenServices services = new RemoteTokenServices();
services.setCheckTokenEndpointUrl("http://localhost:8080/oauth/check_token");
services.setClientId("javaboy");
services.setClientSecret("123");
return services;
}
@Override
public void configure(ResourceServerSecurityConfigurer resources) throws Exception {
resources.resourceId("res1").tokenServices(tokenServices());
}
@Override
public void configure(HttpSecurity http) throws Exception {
http.authorizeRequests()
.antMatchers("/admin/**").hasRole("admin")
.anyRequest().authenticated();
}
}现在迁移到 Spring Security5.x 中之后，我们是这样定义的：
@Configuration
public class MyResourceServer extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http.authorizeRequests()
.anyRequest().authenticated()
.and()
.oauth3ResourceServer()
.opaqueToken()
.introspectionUri("http://localhost:8080/oauth/check_token")
.introspectionClientCredentials("javaboy", "123");
}
}这两段代码作用是一样的。后面的是目前最新写法，不存在过期的问题。
选哪个依赖
现在大家已经知道为什么会存在多种不同的依赖，Spring Cloud Security OAuth3 中使用旧的写法并不会提示过期，但是它同时也支持新的写法，建议小伙伴们用新的写法，反正迟早都要改过来。
看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注亿速云行业资讯频道，感谢您对亿速云的支持。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
