Is Spring Oauth Server replaced if I switch to Okta?

Lucas Favaro 0
Viewed 45

Currently I have an SPA with multiple springboot microservices at the back (Resource Servers). Authentication and Authorization happens in the back using a Spring Oauth2 Server that serves a "Login Page" (Consent Screen) . Inside the Oauth server there is a ldapAuthentication provider that delegates authentication to an Active Directory and the rest (user detail and authorities) is fetched from a jdbc source from a custom data model (groups and privileges). I have the requirement to start using Okta (enterprise). Conceptually speaking, do I have to remove completely the Spring Oauth Server and do everything with Okta regarding Authentication and Authorization? What would be the flow? What happens with the Bearer Token that I currently use? What happens with the introspection of each resource server when applying security access to requests? I am pretty confused what should be the Spring solution for Okta comming from a Spring Oauth Server.

single-page-application spring-security-oauth2 okta
2 Answers

You can replace your Spring OAuth server with Okta Authorization Server, which will require all your micro-services to change their configuration to do the introspection against Okta endpoints. Bearer tokens would be minted by Okta too.

Philipp Grigoryev0

Yes, Okta and Spring OAuth server are both authorization-servers, so you'll probably replace one with the other. The flow will be the same standard OAuth2 authorization-code flow:

  • "rich" client redirects users to authorization-server for authentication (Okta instead of spring authorization-server)
  • authorization-server redirects users back to "rich" client with authorization code
  • "rich" client exchanges authorization-code for access and optionally refresh and ID tokens
  • "rich" client sends request to resource-servers with access-token as Bearer Authorization header
  • resource-servers validate access-tokens and retrieves token claims (either with JWT decoder or introspection) and then evaluates if access should be granted based on token claims

You'll have to refer to Okta docs to add required roles (or groups or authorities and whatever you need in your resource-servers security expressions and that is stored in your LDAP and "JDBC storage") to Okta access-tokens.

If you really have configured your resource-servers with token introspection, you might have to switch to JWT decoding (I haven't search much, but it seams that Okta's introspection endpoint just returns a boolean: isTokenValid). You'll save a lot of resources in the process as JWT validation & decoding happens on resource-server only (it does not require a round-trip to authorization-server for each request as introspection)

ch4mp0
Related