最近一段時間，大家在用 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-projects-experimental/spring-authorization-server

在這個版本中，主要提供了如下功能：

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@EnableResourceServerpublic 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 中之后，我們是這樣定義的：

@Configurationpublic 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 中使用舊的寫法并不會提示過期，但是它同時也支持新的寫法，建議小伙伴們用新的寫法，反正遲早都要改過來。

到此這篇關于Spring Security OAuth過期的解決方法的文章就介紹到這了,更多相關Spring Security OAuth 過期內容請搜索好吧啦網以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持好吧啦網！