Add configuration option for controlling the usage of PKCE when used with OAuth2 confidential clients

[randomstuff]

Currently confidential OAuth2 clients do not use PKCE by default. PKCE can be enabled through code. However, it would be a lot more convenient be have an option to control this using configuration instead. Otherwise everyone has to implement it by theirselves.

PKCE can be used with confidential clients and the the latest drafts suggests to use it even with confidential clients:

• OAuth 2.0 Security Best Current Practice;
• OAuth 2.1 (REQUIRED without OIDC, RECOMMENDED with OIDC).

I think it would make sense to have this enabled by default in the medium term (apparently, there is fear that this might break some authorization servers) so maybe an option whose default value could be changed in the future would be nice.

Related:

• OAuth 2.1 support roadmap
• Consider enabling PKCE for confidential clients
• Create new field in ClientRegistration (e.g. "alwaysPkce") to enable PKCE for confidential clients
• Securing Web Apps Using PKCE With Spring Boot
• Adds option to support IdP that require PKCE for confidential clients

[wilkinsona]

Thanks for the suggestion.

We don't have a great deal of auto-configuration for this and it currently uses Spring Security's defaults for OAuth2 login:

spring-boot/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/security/oauth2/client/servlet/OAuth2WebSecurityConfiguration.java

Lines 56 to 68 in 7c2413f

	@Configuration(proxyBeanMethods = false)
	@ConditionalOnDefaultWebSecurity
	static class OAuth2SecurityFilterChainConfiguration {
	@Bean
	SecurityFilterChain oauth2SecurityFilterChain(HttpSecurity http) throws Exception {
	http.authorizeHttpRequests((requests) -> requests.anyRequest().authenticated());
	http.oauth2Login(withDefaults());
	http.oauth2Client(withDefaults());
	return http.build();
	}
	}

This configuration backs off once any custom security configuration is provided.

I'm not sure that we should start offering properties that are intended to take the place of a Customizer<OAuth2LoginConfigurer<HttpSecurity>> passed to oauth2Login. We would be in danger of trying to recreate Spring Security's DSL in properties and of encouraging people to program through properties.

What's your take on this please, @jgrandja? You said in spring-projects/spring-security#12219 (comment) that "this type of configuration/setting would make more sense in the Spring Boot auto-configuration classes and properties. However, I don't feel it's necessary as the configuration is pretty straight forward". This was 18 months ago so I wonder if your opinion has changed since then.

I think it would make sense to have this enabled by default in the medium term (apparently, there is fear that this might break some authorization servers) so maybe an option whose default value could be changed in the future would be nice.

I don't think this is something that we'd do in Spring Boot as we prefer to keep our defaults aligned with Spring Security's. If you would like to see PKCE enabled by default, please raise a Spring Security issue.

[jgrandja]

@wilkinsona

"this type of configuration/setting would make more sense in the Spring Boot auto-configuration classes and properties..."

My comment was meant to be more of a general statement but I see that I was a conflicting statement instead. To be clear, a "use-pkce" configuration option per client registration would not make sense to add as a Spring Boot property.

We do not want to promote:

We would be in danger of trying to recreate Spring Security's DSL in properties and of encouraging people to program through properties.

@wilkinsona Please close this issue and we'll take it over in spring-security#12219.

@randomstuff Let's take this conversation to spring-security#12219 and see what we can do to simplify things further.

@sjohnr has an idea that he will propose.

[wilkinsona]

Thanks very much, @jgrandja.