CODEWITHSUNDEEP
javaspring-bootauthenticationspring-security
Suhail Ahmed
Suhail Ahmed

Reputation: 357

How to handle Oauth and non-oauth Authorization using spring security in spring boot 3?

In our application which is a spring 5 application, we have both Oauth and Non-Oauth authentication flow, either of the authentication flow can be using a setting.

For oauth we are using an internal authorization server and getting jwt access token.

for non-oauth we are using same internal authorization server's different endpoint which takes username and password and returns a token which is not a jwt token.

So for authorization we are using two different flows where each flow uses different endpoint to validate the token.

now we are upgrading to spring boot 3 and spring webflux, so we are planning to use spring security for protecting the endpoints.

I have explored about the Oauth using spring security and resource server but it handle only Oauth case.

im following https://medium.com/geekculture/jwt-authentication-with-oauth2-resource-server-and-an-external-authorization-server-2b8fd1524fc8 article to understand about the oauth flow.

My doubt is how to handle both Oauth and non-oauth authorization using spring security in spring boot 3 and spring webflux?

Upvotes: 0

Views: 844

Answers (1)

ch4mp
ch4mp

Reputation: 12835

Inferring from comments, your legacy system seems quite easy to integrate in an OAuth2 solution using introspection: use the legacy user-info endpoint to introspect opaque tokens.

That said, you have at least two options for configuring your resource servers:

  • create a single security filter-chain with a custom authentication manager resolver deciding to use JWT decoder or introspection depending on the authorization header format
  • create two separate security filter-chain with security matchers for each type of authorization (one for JWT access tokens and another one for legacy tokens to introspect)

In both cases, the configuration for the "legacy" tokens would be quite standard configuration for resource server with introspection (so called "opaque token" in Spring's doc, even if you can introspect JWTs), with a custom introspector submitting the token to the user-info endpoint you mention in your comments.

The securityMatcher in the second option are probably easier to write than the AuthenticationManagerResolver in the first. You could get inspirations from this security matcher (off course the condition won't be the same for you as you're probably matching a bearer pattern raser than basic string).

Upvotes: 0

Related Questions