I think we should support this.

how do you envision this to work @h4t0n ?

We could support:

micronaut:
  security:
    token:
      jwt:
        signatures:
          jwks:
            google:
              url: 'https://accounts.google.com/'
              type: 'openid-configuration'

and if you specify a type of openid-configuration we search for the jwks_uri exposed in the well-known/openid-configuration

or did you just want to have something like this:

micronaut:
  security:
    oauth2:
      clients:
        google: 
          client-id: '${OAUTH_CLIENT_ID}'  
          client-secret: '${OAUTH_CLIENT_SECRET}' 
          openid:
            issuer: 'https://accounts.google.com' 

We probably need to add a claims validator to ensure we only accept tokens addressed to an OAuth 2.0 client.

What about something like that?

micronaut:
  security:
    oauth2:
      clients:
        google: 
          type: 'verify'
          client-id: '${OAUTH_CLIENT_ID}' 
          openid:
            issuer: 'https://accounts.google.com'

Because here we can use the client-id to validate only its tokens. And do we need the client-secret? I think it can be omitted to verify the token.

I agree with you, client_secret should not be necessary.

Probably, we should not require type: verify either.

The type 'verify' or something similar should be used to disable OAuth login endpoints probably. So it is clear that the OAuth2 configuration is only used to verify tokens.

@h4t0n using authentication mode idtoken should be what you need. We already have a factory which registers the JWKS uri obtained through discovery:

JwksUriSignatureFactory

I've created a PR which includes a claims validator to validate that the aud claim contains the client_id, that the iss matches and for multiple audiences the azp.

So, you will just need:

micronaut:
  security:
    authentication: idtoken
    oauth2:
      clients:
        google: 
          client-id: '${OAUTH_CLIENT_ID}' 
          openid:
            issuer: 'https://accounts.google.com'

Sounds really good. So if I don't use the client-secret It means that no OAuth2 login/logout endpoint are created right?

@h4t0n I have created a PR and a test to ensure the callback routes are not defined if you don't have a client secret:

see:

#475

@sdelamo thanks. Waiting for the merge then.