共计 3703 个字符，预计需要花费 10 分钟才能阅读完成。
最近一段时间，大家在用 Spring Security OAuth2 时可能发现有很多类过期了。
大家在抉择 OAuth2 依赖的时候，可能也会困惑，有好几个中央都能够选：
那么到底抉择哪一个依赖适合呢？这不同的依赖又有什么区别？明天松哥就来和大家聊一聊 Spring Security 中对于 OAuth2 的恩怨。
前言
先来大抵介绍一下 OAuth2 在 Spring 框架中的倒退历程。
大概十年前，Spring 引入了一个社区驱动的开源我的项目 Spring Security OAuth，并将其纳入 Spring 我的项目组合中。到明天，它曾经倒退成为一个成熟的我的项目，能够反对大部分 OAuth 标准，包含 资源服务器 、 客户端 和受权服务器 等。
当初它已成为 UAA（User Account and Authentication Server）的根底。Spring Security OAuth 我的项目已成为一个样板我的项目，它证实了 Spring 社区能够杰出的实现工作。
然而晚期的我的项目存在这样一些问题：
- OAuth 是在很早的时候实现的，开发者无奈意料将来的变动以及这些代码到底要被怎么用，导致很多 Spring 我的项目提供了本人的 OAuth 反对，这就带来了 OAuth2 反对的碎片化。
- 最早的 OAuth 我的项目同时反对 OAuth1.0 和 OAuth2.0，当初 OAuth1.0 早曾经不再应用，能够放弃了。
- 当初咱们有更多的库能够抉择，能够在这些库的根底下来开发，以便更好的反对 JWT 等新玩意。
基于以上这些起因，官网决定在社区胜利的根底上，重写 Spring Security OAuth，以更好地协调 Spring 和 OAuth，并简化代码库，以使 Spring 的 OAuth 反对更加灵便。
然而，在重写的过程中，产生了不少挫折。
2018.01.30
事件得从 2018 年 1 月 30 号讲起。
那天 Spring 官网发了一个告诉，说是要逐步进行现有的 OAuth2 反对，而在 Spring Security5 中构建下一代 OAuth2.0 反对。
为什么要这样呢？
大家晓得，OAuth2 只是一种协定，Spring 框架通过代码对这种协定进行落地。
过后 OAuth2 的落地计划比拟凌乱（这种凌乱到明天仍然存在），在 Spring Security OAuth、Spring Cloud Security、Spring Boot 1.5.x 以及过后最新的 Spring Security5.x 中都提供了对 OAuth2 的实现。
以至于当开发者须要应用 OAuth2 时，不得不问，到底选哪一个依赖适合呢？曾经有三个中央提供了 OAuth2 的反对，曾经够凌乱了，为什么还要在最新的 Spring Security5.x 中持续提供实现呢？
太乱了！
所以 Spring 官网决定有必要将 OAuth2.0 的反对对立到一个我的项目中，以便为用户提供明确的抉择并防止任何潜在的凌乱，同时 OAuth2 的开发文档也要从新编写，以不便开发人员学习。所有的决定将在 Spring Security5 中开始，构建下一代 OAuth2.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 的反对
接下来话锋一转，说了一件很多人难以承受的事件，那就是将 不再提供对受权服务器的反对（要是小伙伴们不懂什么是受权服务器，能够在公众号江南一点雨后盾回复 OAuth2，有松哥写的 OAuth2 教程）。
不提供的起因，官网给了两个：
- 在 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-pro…
在这个版本中，次要提供了如下性能：
- OAuth 2.0 受权代码授予 -RFC 6749
- OAuth 2.0 客户端凭据授予 -RFC 6749
- JSON Web 令牌（JWT）-RFC 7519
- JSON Web 签名（JWS）-RFC 7515
- JSON Web 密钥（JWK）-RFC 7517
- 密钥治理，用于在签订 JWT（JWS）时提供密钥
其余性能还在紧锣密鼓的开发中。
这就是 OAuth2 最近几年的变更之路。
回到问题
回到最开始的问题。
类过期了怎么办？
类过期是因为旧的写法曾经不被反对，松哥举个简略例子，以前咱们定义资源服务器是这样的：
@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()
.oauth2ResourceServer()
.opaqueToken()
.introspectionUri("http://localhost:8080/oauth/check_token")
.introspectionClientCredentials("javaboy", "123");
}
}这两段代码作用是一样的。前面的是目前最新写法，不存在过期的问题。
选哪个依赖
当初大家曾经晓得为什么会存在多种不同的依赖，Spring Cloud Security OAuth2 中应用旧的写法并不会提醒过期，然而它同时也反对新的写法，倡议小伙伴们用新的写法，反正迟早都要改过来。
松哥在四月份的时候出了一个 OAuth2 的教程，过后就是基于 Spring Cloud Security OAuth2 来做的，用了旧的写法，然而没有提醒过期的问题，感兴趣的小伙伴能够看看（公众号后盾回复 OAuth2），无论新旧，只有会其中一个，另外一个上手就很容易了。
当然，前面我也会联合最新的 Spring Security5.x 来更新一套 OAuth2 教程，欢送大家关注～
