Quarkus Security and OIDC/JWT Identity Providers: Boundary Between Bearer-Token Validation and Credential-Expiration Enforcement

Quarkus Security provides pluggable authentication mechanisms, including OIDC authorization-code flow, bearer-token validation, and custom authenticators. An OIDC or JWT identity provider separately manages token issuance, lifetimes, and refresh. At the integration boundary between these components, an unresolved question remains: when a credential is expired, which layer enforces least-privilege rejection, and how is that responsibility documented?

For JWT bearer tokens, Quarkus is generally expected to validate the exp claim before creating a SecurityIdentity, but password or credential expiration is not a standard Quarkus Security concept. Detecting an expired password may require a custom authenticator, identity store, or SecurityIdentityAugmentor, or it may be delegated to the identity provider. The resulting HTTP status and SecurityIdentity behavior can vary by mechanism and Quarkus version.

Assuming Quarkus 3.x with the OIDC extension, is expired-credential enforcement a documented Quarkus Security responsibility, an identity-provider responsibility, or an application-specific integration decision? Where does the documented boundary lie between token validation in Quarkus and credential lifecycle in the IdP? Which extension points, if any, make this behavior explicit rather than implicit?