最近一段時(shí)間，大家在用 Spring Security OAuth2 時(shí)可能發(fā)現(xiàn)有很多類過期了。

大家在選擇 OAuth2 依賴的時(shí)候，可能也會(huì)困惑，有好幾個(gè)地方都可以選：

那么到底選擇哪一個(gè)依賴合適呢？這不同的依賴又有什么區(qū)別？今天松哥就來和大家聊一聊 Spring Security 中關(guān)于 OAuth2 的恩怨。

前言

先來大致介紹一下 OAuth2 在 Spring 框架中的發(fā)展歷程。

大約十年前，Spring 引入了一個(gè)社區(qū)驅(qū)動(dòng)的開源項(xiàng)目 Spring Security OAuth，并將其納入 Spring 項(xiàng)目組合中。到今天，它已經(jīng)發(fā)展成為一個(gè)成熟的項(xiàng)目，可以支持大部分 OAuth 規(guī)范，包括資源服務(wù)器、客戶端和授權(quán)服務(wù)器等。

現(xiàn)在它已成為 UAA（User Account and Authentication Server） 的基礎(chǔ)。Spring Security OAuth 項(xiàng)目已成為一個(gè)樣板項(xiàng)目，它證明了 Spring 社區(qū)可以出色的完成工作。

然而早期的項(xiàng)目存在這樣一些問題：

• OAuth 是在很早的時(shí)候完成的，開發(fā)者無法預(yù)料未來的變化以及這些代碼到底要被怎么用，導(dǎo)致很多 Spring 項(xiàng)目提供了自己的 OAuth 支持，這就帶來了 OAuth2 支持的碎片化。
• 最早的 OAuth 項(xiàng)目同時(shí)支持 OAuth1.0 和 OAuth2.0，現(xiàn)在 OAuth1.0 早已經(jīng)不再使用，可以放棄了
• 現(xiàn)在我們有更多的庫可以選擇，可以在這些庫的基礎(chǔ)上去開發(fā)，以便更好的支持 JWT 等新玩意。

基于以上這些原因，官方?jīng)Q定在社區(qū)成功的基礎(chǔ)上，重寫 Spring Security OAuth，以更好地協(xié)調(diào) Spring 和 OAuth，并簡化代碼庫，以使 Spring 的 OAuth 支持更加靈活。

然而，在重寫的過程中，發(fā)生了不少波折。

2018.01.30

事情得從 2018 年 1 月 30 號(hào)講起。

那天 Spring 官方發(fā)了一個(gè)通知，說是要逐漸停止現(xiàn)有的 OAuth2 支持，而在 Spring Security5 中構(gòu)建下一代 OAuth2.0 支持。

為什么要這樣呢？

大家知道，OAuth2 只是一種協(xié)議，Spring 框架通過代碼對(duì)這種協(xié)議進(jìn)行落地。

當(dāng)時(shí) OAuth2 的落地方案比較混亂（這種混亂到今天依然存在），在 Spring Security OAuth、Spring Cloud Security、Spring Boot 1.5.x 以及當(dāng)時(shí)最新的 Spring Security5.x 中都提供了對(duì) OAuth2 的實(shí)現(xiàn)。

以至于當(dāng)開發(fā)者需要使用 OAuth2 時(shí)，不得不問，到底選哪一個(gè)依賴合適呢？已經(jīng)有三個(gè)地方提供了 OAuth2 的支持，已經(jīng)夠混亂了，為什么還要在最新的 Spring Security5.x 中繼續(xù)提供實(shí)現(xiàn)呢？

太亂了！

所以 Spring 官方?jīng)Q定有必要將 OAuth2.0 的支持統(tǒng)一到一個(gè)項(xiàng)目中，以便為用戶提供明確的選擇并避免任何潛在的混亂，同時(shí) OAuth2 的開發(fā)文檔也要重新編寫，以方便開發(fā)人員學(xué)習(xí)。所有的決定將在 Spring Security5 中開始，構(gòu)建下一代 OAuth2.0 的支持。

從那個(gè)時(shí)候起，Spring Security OAuth 項(xiàng)目就正式處于維護(hù)模式。官方將提供至少 1 年的錯(cuò)誤/安全修復(fù)程序，并且會(huì)考慮添加次要功能，但不會(huì)添加主要功能。同時(shí)將 Spring Security OAuth 中的所有功能重構(gòu)到 Spring Security5.x 中。

老實(shí)說，這是一個(gè)英明的決定，當(dāng)時(shí)并沒有引起太多的反響。但是接下來的事情就不是那么順利了。

2019.11.14

時(shí)間到了 2019.11.14。

這天，官方又發(fā)了個(gè)通知。

先說了 Spring Security OAuth 在遷往 Spring Security5.x 的過程非常順利，大部分遷移工作已經(jīng)完成了，剩下的將在 5.3 版本中完成遷移，在遷移的過程中還添加了許多新功能，包括對(duì) OpenID Connect1.0 的支持

接下來話鋒一轉(zhuǎn)，說了一件很多人難以接受的事情，那就是將不再提供對(duì)授權(quán)服務(wù)器的支持（要是小伙伴們不懂什么是授權(quán)服務(wù)器，可以在公眾號(hào)江南一點(diǎn)雨后臺(tái)回復(fù) OAuth2 ，有松哥寫的 OAuth2 教程）。

不提供的原因，官方給了兩個(gè)：

在 2019 年，將有大量的商業(yè)和開源授權(quán)服務(wù)器可用。授權(quán)服務(wù)器是使用一個(gè)庫來構(gòu)建產(chǎn)品，而 Spring Security 作為框架，并不適合做這件事情。

一石激起千層浪，許多開發(fā)者表示對(duì)此難以接受。這件事也在 Spring 社區(qū)引發(fā)了激烈的討論，好在 Spring 官方愿意傾聽來自社區(qū)的聲音。

2020.04.15

這天，官方又發(fā)了個(gè)通知。

這次宣布了 Spring Authorization Server 項(xiàng)目。這是一個(gè)由 Spring Security 團(tuán)隊(duì)領(lǐng)導(dǎo)的社區(qū)驅(qū)動(dòng)的項(xiàng)目，致力于向 Spring 社區(qū)提供 Authorization Server 支持。

官方傾聽了來自社區(qū)的聲音，決定繼續(xù)提供授權(quán)服務(wù)器。

這次只是宣布了一下，算是安撫了一下社區(qū)的情緒，但是項(xiàng)目還沒開發(fā)出來。

2020.08.21

Spring Authorization Server 0.0.1 正式發(fā)布！

同時(shí)公布了項(xiàng)目源碼地址：https://github.com/spring-projects-experimental/spring-authorization-server

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

• OAuth 2.0授權(quán)代碼授予  -RFC 6749
• OAuth 2.0客戶端憑據(jù)授予  -RFC 6749
• JSON Web令牌（JWT）  -RFC 7519
• JSON Web簽名（JWS）  -RFC 7515
• JSON Web密鑰（JWK）  -RFC 7517
• 密鑰管理，用于在簽署JWT（JWS）時(shí)提供密鑰
  

其他功能還在緊鑼密鼓的開發(fā)中。

這就是 OAuth2 最近幾年的變更之路。

回到問題

回到最開始的問題。

類過期了怎么辦？

類過期是因?yàn)榕f的寫法已經(jīng)不被支持，松哥舉個(gè)簡單例子，以前我們定義資源服務(wù)器是這樣的：

@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();
  }
}

現(xiàn)在遷移到 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");
  }
}

這兩段代碼作用是一樣的。后面的是目前最新寫法，不存在過期的問題。

選哪個(gè)依賴

現(xiàn)在大家已經(jīng)知道為什么會(huì)存在多種不同的依賴，Spring Cloud Security OAuth2 中使用舊的寫法并不會(huì)提示過期，但是它同時(shí)也支持新的寫法，建議小伙伴們用新的寫法，反正遲早都要改過來。

到此這篇關(guān)于Spring Security OAuth過期的解決方法的文章就介紹到這了,更多相關(guān)Spring Security OAuth 過期內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！