Lightest setup for jwt resource server

[BenVella]

With reference to https://www.baeldung.com/spring-boot-keycloak and this repo's samples I was able to get most of the way there.

• The example that worked for me was from baeldung samples: baeldung-tutorials\spring-boot-modules\spring-boot-keycloak but that wasn't using spring-addons.
• It defined its own custom security filter which I was hoping to avoid entirely, as per this repo's author suggestion since I'm relatively blind to spring security, even after reading as much documentation as I could to wrap my head around oauth and oidc concepts.
• I would like to switch over to the addon with the hope of not even needing to define a security filter chain (assuming that's possible) with keycloak as the provider but I'm encountering the issue:

com.c4_soft.springaddons.security.oidc.starter.properties.NotAConfiguredOpenidProviderException: Could not resolve OpenID Provider configuration properties from a JWT with http://localhost:8442/realms/baeldung-keycloak as issuer and [account] as audience

• In truth I'm using the baledung's tutorial included keycloak json data import file, with one simple edit to allow direct access (not planning to have a front end but use directly via postman)

The inspected token generated by keycloak told me:

 "iss": "http://localhost:8442/realms/baeldung-keycloak",
  "aud": "account",

For full details on the setup (keycloak branch): https://github.com/BenVella/backend-java/tree/keycloak

My properties are:

# See https://github.com/ch4mpy/spring-addons/blob/master/samples/webmvc-jwt-default
com:
  c4-soft:
    springaddons:
      oidc:
        cors:
          - path: /**
            allowed-origin-patterns: ${origins}
        ops:
          - iss: http://localhost:8442/realms/baeldung-keycloak
            username-claim: preferred_username
            authorities:
              - path: $.realm_access.roles
              - path: $.resource_access.*.roles
        resourceserver:
          permit-all:
            - /no-op
            - /greet/public
            - /actuator/health/readiness
            - /actuator/health/liveness
            - /v3/api-docs/**

And keycloak is on docker compose with similar details. It's probably incredibly obvious but I can't quite work out why it's not resolving an appropriate OpenId Provider...

[BenVella]

And... it looks like it boils down to me always running cached builds. I need to look into that cause it's happened a few times already. Copy pasting the expected url did solve the issue but I was then running the cached build with the originally wrong properties🤦

That then meant that the issuer-uri was correct but not reachable. I was very confused on that front so I tried adding expose:8442 for keycloak. It didn't matter, it was always targeting localhost:8442, but localhost meant the app's own localhost.

Solution was changing it to keycloak:8442 in issuer uri to reach that container, but of course that sent me back to the original error, keycloak was minting its tokens and marking itself as issuer on localhost. So updating keycloak's docker compose to:

      KC_HTTP_PORT: 8442
      KC_HOSTNAME: keycloak
      KC_HOSTNAME_STRICT: true

Just to cover the basics for whichever poor soul finds themselves in my position, the above will mint jwts with issuer http://keycloak:8442/realms/baeldung-keycloak

com:
  c4-soft:
    springaddons:
      oidc:
        cors:
          - path: /**
            allowed-origin-patterns: ${origins}
        ops:
          - iss: http://keycloak:8442/realms/baeldung-keycloak
            username-claim: preferred_username
            authorities:
              - path: $.realm_access.roles
              - path: $.resource_access.*.roles
        resourceserver:
          permit-all:
            - /no-op
            - /greet/public
            - /actuator/health/readiness
            - /actuator/health/liveness
            - /v3/api-docs/**

[ch4mpy]

Hi @BenVella,

In the Baeldung tutorial for getting started with Keycloak, only Keycloak is deployed in Docker. The Spring OAuth2 clients and resource servers are intended to run in debug mode from an IDE. As Spring applications run on the host machine and not a container, they resolve localhost to that same host machine, and as Keycloak is exposed by Docker on the port 8080 of the host machine, http://localhost:8080 is correctly resolved. Now, if you run Spring applications within Docker container, you can't use localhost anymore to perform OIDC configuration (because, as you figured out, localhost is resolved to the container, not to the host machine). An option is to use the machine hostname (value of the $HOSTNAME environment variable or hostname command) and to configure Keycloak to use the same hostname each time it provides its issuer identifier in a payload (OpenID conf, tokens iss claim, ...)

Also, you are using Keycloak 26 and the tutorial is using an early 25. Between these versions, hostname configuration has changed. That's why I used KC_HOSTNAME_URL in the tutorial and you have to use KC_HOSTNAME.

Last, you seem to be using Angular as front end. Be aware that Spring Security team discourages to use public clients (Angular apps can only be public OAuth2 clients). I wrote another Baeldung article to implement the OAuth2 BFF pattern where the OAuth2 client is a Spring Cloud Gateway instance, not the Angular app.

As a side note, if you're interested in getting a better understanding of OAuth2 / OpenID / OIDC & the corresponding parts of Spring Security, I propose some training sessions: https://jw.c4-soft.com/ui/en-US/trainings/spring-openid