activity-based-security-framework VS Spring Security

Throughout my years working in the IT sphere, I’ve had the opportunity to work on projects in a variety of fields. Even though the process of authenticating requirements remained relatively consistent, methods of implementing the authorization mechanism tended to be quite different from project to project. Authorization had to be written practically from scratch for the specific goals of each project; we had to develop an architectural solution, then modify it with changing requirements, test it, etc. All this was considered a common process that developers could not avoid. Every time someone implemented a new architectural approach, we felt more and more that we should come up with a general approach that would cover the main authorization tasks and (most importantly) could be reused on other applications. This article takes a look at a generalized architectural approach to authorization based on an example of a developed framework.

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).