okta-spring-boot | Okta Spring Boot Starter | Security library

the SAML bearer assertion flow of OAuth does help in fetching an OAuth token (access-token) using a SAML Assertion as described here: https://docs.microsoft.com/en-us/azure/active-directory/develop/scenario-token-exchange-saml-oauth

Take a look at the "Authorization Server" section in the blog post you mentioned:

https://developer.okta.com/blog/2017/10/13/okta-groups-spring-security#authorization-server

The post used an older version of these libraries, but make sure you have the "groups" claim defined. You likely need to set the "include in token type" value to "both" (or follow the same steps to create one for the "ID Token" as well)

This post likely predated OIDC support in Spring Security.

Keep us posted, if that was the issue I'll tweak the post to mention that.

If that doesn't help, use the "Token Preview" tab on the "Authorization Server" configuration page in your Okta Admin/Developer Console. You should see a "groups" claim listed, once everything is configured correctly.

Update (answering other questions):

1. ID Token vs Access Token claims This gets into the weeds a bit related to the OAuth 2.0 and OIDC specs. But the TL;DR is older versions of Spring Security used OAuth 2.0 and Access Tokens, newer versions can use OIDC and ID Tokens.

   There are other flows that would use Access Tokens too, for a more detailed description on the differences between the two and which flows use which tokens, checkout the Okta Dev YouTube Channel

2. This one was my fault, I miss remembered this page. You can just create the claim for both token types.

3. It uses the names that are in group, if you want it to use ROLE_ADMIN instead you can create an Okta group with that name.

You should be able to mock things so OIDC discovery can happen. I show how to do it for a JHipster app in this blog post. Since you're using the Okta Spring Boot starter, I'm guessing you can do something like this.

1. Create a TestSecurityConfiguration.java class.

If the spring boot application has no enforcement of security, what is to prevent someone from bypassing the Apigee API gateway and calling it directly?

If you have successfully managed to secure the spring boot application so that only the API gateway can communicate with it (via mutual TLS connection, IP allow listing, etc), you might be able to forego any enforement at the service level, but I would recommend doing some authorization checks in the service itself.

It turned out, the solution is to remove the cookie header from the downstream request. This can be achieved by adding another default filter to the gateway:

Please clean your gradle.build file from hibernate dependencies , spring-jdbc and spring-orm. As spring-boot-starter-jpa has hibernate as transitive dependency.