Change in Quarkus SmallRye JWT expiration tolerance leads to downstream expiry state inconsistency

Short answer

Yes, this split is expected behavior. In Quarkus 3.2+, quarkus.jwt.token.expire-tolerance widens only the acceptance check performed by the SmallRye JWT validator. It does not rewrite the token's claims. JsonWebToken.getExp() (and the raw claim set used for propagation) still returns the original exp value, so anything inspecting the token after validation — logs, audit code, token propagation to another service — will see a timestamp in the past even though the request was admitted.

Likely explanation vs. confirmed facts

Confirmed: the tolerance is applied at validation time only; the parsed claim set is passed through unchanged. There is no built-in property that shifts the internal exp value to match the tolerance.

Likely explanation (not officially documented as design intent): keeping the original claim preserves auditability and avoids silently extending a token's effective lifetime in places the framework cannot see. If Quarkus rewrote exp, a propagated token would appear valid downstream for longer than the issuer intended, which is arguably worse than the inconsistency you're hitting. So treat this as security-by-design rather than an oversight, and assume it will not change.

What you can do

There is no configuration to align the internal expiry with the tolerance. Your options, in order of preference:

1. Recompute validity where you need it. In audit/logging code, compare getExp() against now - tolerance instead of now. This keeps the raw claim intact and makes your internal view consistent with the acceptance decision.
2. Decorate the token for internal use. Wrap the injected JsonWebToken (e.g., via a CDI decorator or a request-scoped bean) and expose an adjusted expiry — exp + tolerance — only for your internal consumers. Do not mutate the underlying claim set used for propagation.
3. Handle propagation explicitly. If a downstream identity provider or introspection call rejects the near-expired token, that is the downstream system applying its own (stricter) check. No client-side change can force it to honor your tolerance; either shorten token lifetimes so the window rarely matters, or refresh the token before propagating.

Verification

Set a known tolerance and confirm the split directly:

quarkus.jwt.token.expire-tolerance=10

Issue a JWT with exp five seconds in the past. The request should succeed while a log of jwt.getExpirationTime() shows a past instant. Then issue one with exp 15 seconds in the past — it must be rejected with 401. If you add a decorator, repeat the first test and confirm your internal view reports a future expiry while the raw claim is unchanged.

Caution

Keep the tolerance small (seconds, not minutes). Any wrapper that makes an expired token look valid internally can weaken replay detection in your own audit trail, and must never bypass signature, issuer, or audience validation — those are unaffected by this property and should stay that way.