Programmatic OIDC startup

[sberyozkin]

Description

Currently, Quarkus OIDC users usually use properties to initiate the OIDC startup (connection, discovery, JWK set retrieval).
They can also use TenantConfigResolver to create OIDC tenants dynamically - but it happens at the request time.

It would be good to support programmatic OIDC startup, for users to be able to do it in main() or in Startup event handlers.

This enhancement will serve 2 purposes:

• Help users who are not too keen on dealing with properties just to do some simple code and be done with it.
• Help users who are migrating to Quarkus OIDC and prefer the programmatic setup

Implementation ideas

Now that we have an OIDC builder support, we can try something like:

public void main() {
    // Enough for simple bearer token scenarios
    Oidc.start(OidcTenantConfigBuilder.authServerUrl("....").build());

   // code flow
   Oidc.start(OidcTenantConfigBuilder.authServerUrl("....").applicationType(WEB_APP)
        clientId(...)
        credentials().clientSecret("").end()
  .build());
    
}

etc

[quarkus-bot]

/cc @pedroigor (oidc)

[michalvavrik]

I'll put this very high on my list, somewhere near to the top, but I think this needs proper discussion. For me, this Oidc of the Oidc.start(... basically represents couple of objects:

• io.quarkus.vertx.http.runtime.security.HttpAuthenticationMechanism
• Dev Service startup
• TenantConfigBean
• DefaultTokenIntrospectionUserInfoCache
• and others

Or maybe you mean that Oidc just represent tenants. We can't exactly register CDI beans after CDI container were setup. I also think this issue is related to the #16728, though I don't know in which way ATM.

[sberyozkin]

Thanks @michalvavrik, sure let's think more about how to do it.

I haven't thought about details yet, but at the high level, I'm imagining it will be done very similar to the way DefaultTenantConfigResolver creates tenants dynamically, we get OidcTenantConfig which users will prepare with the builder, and Oidc.create will use the same function which DefaultTenantConfigResolver does to create the tenant.

May be it should not be Oidc.create(config) but @Inject Oidc oidc; oidc.create(config);, as indeed, users should be able to create many tenants, so the latter option might help connect it all with DefaultTenantConfigResolver (or TenantConfigBean).

#16728 is related, indirectly, #16728 may need to be done at some point to let Oidc.create (and other mechanisms) to work with HTTP security policies (instead of configuring them), but Oidc.create will work fine with the annotation based endpoints, including named policy annotations.

May be, once we do this one, we can give #16728 a try to have whatever programmatic OIDC setup which will be available after this PR working with programmatically prepared HTTP policies.

[michalvavrik]

thanks for your thoughts

May be it should not be Oidc.create(config) but @Inject Oidc oidc; oidc.create(config);

+1, because whether OIDC is enabled or disabled must be done during the build time, but we can support what you describe during the application startup without big issues and I think it will be extendable if in the future more things should be configured.