Resource Server won't compile without Client ID

[joncatanio]

Hello 👋 I'm currently working on a project with webflux and the okta-spring-boot-starter. I'm configuring a resource server that has a few endpoints and validates JWTs minted from my Okta auth server. Unfortunately I receive the following compilation error:

Error creating bean with name 'spring.security.oauth2.client-org.springframework.boot.autoconfigure.security.oauth2.client.OAuth2ClientProperties': Invocation of init method failed; nested exception is java.lang.IllegalStateException: Client id must not be empty.

My application properties file looks something like this:

okta:
  oauth2:
    issuer: {auth_server_uri}
    audience: api://default
    scopes:
      - {valid_scope}

Notice I don't include okta.oauth2.client-id, this seems to cause the compilation error. However, if I set that property to any string, e.g. okta.oauth2.client-id: 123, I no longer get compilation errors and I am able to hit my controller endpoints with Spring Security handling the JWT validation correctly and everything.

So I have two questions, if I'm building a resource server, why do I need to specify a client-id when my API plans to receive JWTs minted at one auth server and requested from various clients? Second, why is it that when I add the client-id property it seems to be completely unchecked, only validating the signing key, audience, and scopes?

I have used the Okta SDK where I explicitly built the com.okta.jwt.JwtVerifier and made explicit calls to .setIssuerUrl(...) and .setAudience(...), and there I was not required to call .setClientId(...).

Any help would be appreciated, thanks!

[bdemers]

Thanks for the report @joncatanio!

This was fixed in 3c13bc7
(i'm kicking off a new release today), it should be available in a couple hours.

[joncatanio]

@bdemers Hi Brian, I was able to bump my version and I see it working, however I have one more quick question for you.

When I bumped the version I still received the "Client id must not be empty" error. I noticed that when I removed scopes from my properties file that it would correctly compile and the resource server worked. It appears that including scopes attempts to validate registration for a server side application, rather than behave as a resource server.

My question is, doesn't this make scopes obsolete for resource servers? Isn't this something that we can leverage to limit access to specific resources. Perhaps I'm misunderstanding the OAuth2 spec, but any light you could shed on this would be greatly appreciated.

[bdemers]

I'll write a test for this.

scopes should have a default value (email profile openid from Spring Security IIRC) so it shouldn't matter if it is set or not.

Do you have any other Spring OAuth2 properties set? Or is it basically just something like:

okta:
  oauth2:
    scopes: 
    - foo
    - bar 

Thanks for following up!!!

[joncatanio]

The properties I have set are the exactly this (with a valid auth server uri, of course):

okta:
  oauth2:
    issuer: {auth_server_uri}
    audience: api://default
    scopes:
      - openid

I only had openid set, but I was thinking in the future I'd want to set up a custom scope and include it here. It seems like in that case I wouldn't be able to do that because it would fail to compile (due to unspecified clientId.

For now I've just omitted the scopes and it appears to work just fine, but again, not ideal if I wanted to add scopes.

The app I had setup was literally just a quick initializr with the Okta starter and Webflux. Added the above and properties and a dummy controller (as followed by the README) and it failed to compile.