fix: no routes for OAuth 2.0 clients with nosecret

[sdelamo]

close: https://github.com/micronaut-projects/micronaut-security/issues/439

When would you want an OAuth 2.0 Client with no secret? You want to have the minium security configuration in place to be able to validate idtokens.

E.g. you have two services

[Gateway]

[Repository]

Gateway has the config:

micronaut:
  security:
     authentication: idtoken
     oauth2:
        clients:
            cognito:
               client-id: 'xxx'
               client-secret: 'xxx'
               openid:
                    issuer: 'https://blablaba'

The gateway does the authorization code grant flow with cognito and gets an idtoken.

To communicate with repository service it passes the id token as a bearer token.

Repository does not need callback routes. It just needs the minimum config to register the JWKS endpoint obtained via cognito well-know/openid-configuration to be able to validate the idtoken the gateway includes in the request headers.

This will be the config for repository:

micronaut:
  security:
     authentication: idtoken
     oauth2:
        clients:
            cognito:
               client-id: 'xxx'
               openid:
                    issuer: 'https://blablaba'

[sdelamo]

@jameskleeh could you review this ?

[jameskleeh]

@sdelamo To me this is better implemented by supporting an issuer property in JwksSignatureConfigurationProperties

micronaut.security.token.jwt.signatures.jwks.*.openid-issuer: 'https://blablaba'

That is more clear what the intent is and doesn't require additional checks in the oauth logic

[sdelamo]

We need the client-id in addition to the issuer because we need to validate the claims to avoid accepting every token issued by google for example.

When you are in authentication mode idtoken, we create an id token Claims validator.

we could support:

micronaut.security.token.jwt.signatures.jwks.*.oauth2-openid-issuer: 'https://blablaba'
micronaut.security.token.jwt.signatures.jwks.*.oauth2-client-id: 'XXXX'

And I could create a claims validator for each JwksSignature with such configuration.

@jameskleeh thoughts?