Okta Spring Boot Starter VS Spring Security

Okta also now has an Okta Spring Boot starter. I didn't use it in my first experiment, but I'm a big fan of it after the last few years! It dramatically simplifies configuration and makes securing your apps with OAuth 2.0 and OIDC easy. It's a thin wrapper around Spring Security's resource server, OAuth client, and OIDC features. Not only that, but it works with Okta Workforce Identity, Okta Customer Identity (aka Auth0), and even Keycloak.

looks like these, the api, sdk, and the httpclient are basically what the okta saml spring boot starter are wrapping (https://github.com/okta/okta-spring-boot/blob/master/okta-spring-boot-starter/pom.xml). so you should be able to call those directly.

okta: Okta Spring Boot Starter that helps OAuth 2.0 and OIDC configuration

If you'd rather use Auth0, that's possible too! First, you'll need to use the Spring Security dependencies as mentioned above. The Okta Spring Boot starter currently doesn't work with Auth0.

Spring security has long had great OAuth2.0 support from both the server and client elements. Recently spring security added support for the private_key_jwt client authentication method as part of the authorization code grant flow. Spring Security GitHub ref

To be fair there were quite some unexpected surprises in the past with Spring and Kotlin (e.g. the Cachable annotation did not work with suspend functions, not all Spring security annotations were supported with coroutines), but most of them were ironed out already.

They recently updated all the examples in the javadocs if you wanna bump your Spring Security version to 5.7.3 (see here). Otherwise the reference docs all reflect the non-deprecated approach that uses SecurityFilterChain and supporting beans.

Spring Security 5.7

Since Spring Security 5.7.0-M2 the use of WebSecurityConfigurerAdapter was deprecated (link to GitHub - https://github.com/spring-projects/spring-security/issues/10822) to move to component-based security configuration.

When i start the flow, no proxy is used and even the WebClient is not used to get access token. And i get a timeout exception for that. The same issue was discussed in Github: https://github.com/spring-projects/spring-security/issues/8966

You can extract (and validate) the JWT token into the Principal by implementing the getPreAuthenticatedPrincipal method, and map the claims to user details by providing through a custom implementation of AuthenticationUserDetailsService.

Or, maybe simpler, is to create your own filter and add it after the SecurityContextPersistenceFilter. Here, just recreate the authentication token from the database, which is what token based authentication does (token based authentication has to preauthenticated authentication from the token for the actual user authentication with the user details).