Introduce quarkus.oidc (or quarkus.security) strict profile

[sberyozkin]

Description

Some OIDC properties which enable stricter security are not activated by default, for example, quarkus.oidc.authentication.pkce-required (as noticed by @pedroigor), to be introduced nonce might not be for web-app applications. This is compensated by the fact the if the client secret is set then the code would still be well-protected, but there extra safety measures will never hurt.

Also, forceRedirectHttpsScheme (i.e, we really don't want HTTP only endpoints doing the code flow, so if enforcing it if http is only a proxy thing would not be a problem, also suggested for the apple profile by @FroMage), expected token type is optional (if we can deduce it is Keycloak we can enforce the type, id/access/refresh), etc.

By introducing a strict profile we can enforce that these and other relevant properties are enabled/enforced. This profile can be also activated by default and the users would then override some specific properties.

This idea of a strict profile can be relevant not only to oidc but other security extensions. For ex, requiring the authentication by default, etc

Implementation ideas

Probably introduce quarkus.security.strict=true and then start from oidc and then keep going and check other security extensions (in follow up issues)

[quarkus-bot]

/cc @pedroigor

[sberyozkin]

@pedroigor As part of this work for OIDC we can check the discovery document and enable PKCE, or check the supported algorithms and enforce the tokens are signed with one of those algorithms, etc, we can make it pretty extensive.
I have to admit it may take a bit of time to prioritize but I'm positive about your idea, thanks :-)

[pedroigor]

@sberyozkin Sure, that was just something I thought and related to how we are re-thinking our configuration model. Having better/secure defaults while still giving some flexibility for dev/testing.