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

Question

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?

Tasadduq Burney · Answer

Direct answer
In Quarkus 3.x with the OIDC extension, expired-credential enforcement is not a single documented Quarkus Security responsibility. It is split at the boundary: Quarkus validates the presented bearer token and rejects an expired exp claim before creating a SecurityIdentity, while password, account, refresh-token, and session expiration remain the identity provider's responsibility or an application-specific integration decision. Quarkus has no standard concept of password expiration that the OIDC extension enforces automatically.
Confirmed behavior versus assumptions
Confirmed within the limits of the supplied brief: JWT bearer validation, including signature, issuer, audience, and exp, is performed by Quarkus/SmallRye JWT during authentication. An expired exp normally causes authentication failure, typically HTTP 401, before a SecurityIdentity exists. Password expiration is not part of that validation.
Assumed and requiring version verification: the exact HTTP status, WWW-Authenticate header, refresh-token failure behavior, and whether an augmentor can reject an identity depend on the Quarkus minor version and SmallRye JWT release. Treat status-code contracts as version-specific until checked against the target release notes. This draft should be reviewed against the target Quarkus release notes before operational use.
Where the boundary lies

LayerResponsibility

Quarkus OIDC / JWT bearer mechanismValidates the access token presented on the request, including exp, and rejects untrusted or expired tokens before identity creation.
Identity providerOwns credential issuance, lifetimes, refresh, rotation, revocation, and password or account expiration. Enforces those at its token, authorization, or introspection endpoints.
Application integrationDecides how to detect an expired password or stale credential when a valid bearer token is still presented, using custom code or IdP signals.

Extension points that make the behavior explicit

Authenticator or IdentityStore: custom password-expiry or credential-staleness checks before or during authentication.
SecurityIdentityAugmentor: post-validation augmentation; can add roles or metadata, but is not designed as an authentication rejection point and should not be relied on to refuse a valid token.
Bearer-token / OIDC authentication mechanism: performs default exp rejection implicitly; no separate configuration flag turns credential expiration on or off.
JsonWebToken / JwtParser: exposes claims for inspection after parsing, but does not enforce IdP-side password lifecycle.

Verification steps for this case

Confirm the Quarkus 3.x minor version and whether the app uses OIDC authorization-code flow or JWT bearer-only mode; this changes where refresh and session expiry are enforced.
Send a JWT with a past exp as Authorization: Bearer and confirm the request fails before SecurityIdentity creation, typically with 401.
Enable DEBUG logging for io.quarkus.oidc and io.smallrye.jwt to verify rejection occurs at token parsing or validation, not later augmentation.
Test an expired password with a still-valid access token after adding IdP checks or a custom authenticator/identity store to confirm whether Quarkus accepts or rejects the token.

quarkus.log.category."io.quarkus.oidc".level=DEBUG
quarkus.log.category."io.smallrye.jwt".level=DEBUG
Missing diagnostic detail: the Quarkus minor version and OIDC mode in use. This changes the recommendation because refresh-token expiration and status-code behavior differ across versions.

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

1 answer

Direct answer

Confirmed behavior versus assumptions

Where the boundary lies

Extension points that make the behavior explicit

Verification steps for this case

Your perspective belongs here.

0 question comments

Layer	Responsibility
Quarkus OIDC / JWT bearer mechanism	Validates the access token presented on the request, including `exp`, and rejects untrusted or expired tokens before identity creation.
Identity provider	Owns credential issuance, lifetimes, refresh, rotation, revocation, and password or account expiration. Enforces those at its token, authorization, or introspection endpoints.
Application integration	Decides how to detect an expired password or stale credential when a valid bearer token is still presented, using custom code or IdP signals.