This article looks at the configuration of OAuth 2.0 Authorization Server related filters. In turn, it provides a better understanding of the entire architecture of Spring Authorization Server.

Modular configuration of Spring Security

Currently OAuth2.0 Client, Resource Server, Authorization Server these are already modularized in the Spring Security system. So how do they achieve flexible modularity? After analyzing the configuration I found a few similarities below.

These are the core configuration classes of OAuth2.0 Client.

1
2
3
4
public final class OAuth2ClientConfigurer<B extends HttpSecurityBuilder<B>>
        extends AbstractHttpConfigurer<OAuth2ClientConfigurer<B>, B> {
    // 省略
}

This is the core configuration class for OAuth2.0 Resource Server.

1
2
3
4
public final class OAuth2ResourceServerConfigurer<H extends HttpSecurityBuilder<H>>
        extends AbstractHttpConfigurer<OAuth2ResourceServerConfigurer<H>, H> {
    // 省略
}

This is the core configuration class for OAuth2.0 Authorization Server.

1
2
3
4
public final class OAuth2AuthorizationServerConfigurer<H extends HttpSecurityBuilder<H>>
        extends AbstractHttpConfigurer<OAuth2AuthorizationServerConfigurer<H>, H> {
    // 省略
}

Their configuration classes all inherit from AbstractHttpConfigurer<T> and are ultimately loaded into Spring Security by apply(C configurer) of HttpSecurity.

What does this mechanism tell you? Is it possible to implement some custom functional configurations?

Configuration of Spring Authorization Server

Based on 0.2.0 version.

In the DEMO Spring Authorization Server introduces the relevant functionality with the following configuration.

1
2
3
4
5
6
7
@Bean
@Order(Ordered.HIGHEST_PRECEDENCE)
public SecurityFilterChain authorizationServerSecurityFilterChain(HttpSecurity http) throws Exception {
    // Authorization Server 默认配置
    OAuth2AuthorizationServerConfiguration.applyDefaultSecurity(http);
    return http.formLogin(Customizer.withDefaults()).build();
}

A separate SecurityFilterChain is constructed to load the configuration of the authorization server, separate because HttpSecurity is injected Spring IoC based on a prototype (@Scope("prototype")). The associated requests are then processed by that filter chain. Let’s see what these filter chains have next.

OAuth2AuthorizationServerConfigurer

This class is responsible for configuring the Spring Authorization Server filter chain. It is responsible for the following configurations.

OAuth2ClientAuthenticationConfigurer

This configuration class is used to configure the OAuth2ClientAuthenticationFilter, which is used to process OAuth2.0 Client authentication requests and is used to query OAuth2.0 Client registration information OAuth2ClientAuthenticationToken. The following three endpoints are intercepted by this filter.

  • /oauth2/token Get token endpoint.
  • /oauth2/introspect The token introspection endpoint.
  • /oauth2/revoke The token revocation endpoint.

OAuth2AuthorizationEndpointConfigurer

This configuration class is used to configure the OAuth2AuthorizationEndpointFilter, which is used to handle OAuth 2.0 Authorization Code Grant authorization requests /oauth2/authorize and contains the user’s secondary confirmation (*Consent) logic. *) logic.

OAuth2TokenEndpointConfigurer

This configuration class is used to configure the OAuth2TokenEndpointFilter, which is used to handle the /oauth2/token endpoint request and manage the lifecycle of the managed OAuth2.0 token.

OidcConfigurer

This configuration class is used to provide support for the OIDC protocol. There are two filters.

  • OidcClientRegistrationEndpointFilter, which is used to handle /connect/register endpoint requests and implement OpenID Connect 1.0 dynamic client registration requests.
  • OidcProviderConfigurationEndpointFilter that provides OIDC Provider meta-configuration information via the /.well-known/openid-configuration endpoint.

Other filters

In addition to the above, there are several filters that can be configured flexibly via their respective Configurers. There are also some filters that are not currently openly configurable.

  • OAuth2TokenIntrospectionEndpointFilter, which handles /oauth2/introspect token introspection logic.
  • OAuth2TokenRevocationEndpointFilter to handle token revocation logic
  • NimbusJwkSetEndpointFilter, used to handle the logic for the JWK message URI endpoint /oauth2/jwks.
  • OAuth2AuthorizationServerMetadataEndpointFilter , used to provide logic for the OAuth2.0 authorization server metadata access endpoint /.well known/oauth-authorization-server.

Summary

These are all the server endpoints involved in the Spring Authorization Server, and you can guess the filter logic executed by the corresponding endpoints with the DEMO provided in the previous article. However, it seems that there is no user information UserInfo endpoint yet. According to the Spring Authorization Server roadmap, this endpoint will be supported in the next release, and I will add it then.

Reference https://felord.cn/spring-authorization-server-filters.html