Make ID Token iat validation configurable (relaxed for refresh token flows)

Is your feature request related to a problem you're having? Please describe.
Yes.

In refresh token flows (e.g., biometric unlock scenarios), strict ID Token iat validation can cause false negatives due to device clock drift.

This occurs even when:

• the refresh token exchange succeeds server-side
• the returned tokens are valid
• other validations (exp, signature, iss, aud) pass

In these cases, the client rejects the response solely due to iat skew, leading to failed session restoration and degraded user experience.

Describe the solution you'd like
Introduce a way to configure or relax iat validation, while keeping the current strict behavior as the default.

Possible approaches:

• Allow injecting a custom validation policy for ID Tokens
• Provide a flag to relax or disable iat validation
• Allow configuring validation behavior specifically for refresh token flows

This would preserve secure defaults while enabling apps with different trust models (e.g., biometric-gated refresh) to handle this scenario appropriately.

Describe alternatives you've considered

• Increasing clock skew tolerance → already set to 10 minutes, but still insufficient in some real-world scenarios
• Catching and recovering from the error → possible, but indirect and not ideal
• Forking the library to modify validation → introduces long-term maintenance burden
• Bypassing the library for refresh flows and implementing custom token handling → viable, but duplicates functionality already present in the library

Additional context

The OpenID Connect Core §3.1.3.7, rule 10 states:

The iat Claim can be used to reject tokens that were issued too far away from the current time [...]

Two relevant observations:

• Non-normative language

  • The spec says “can be used”, not “MUST”. Unlike exp (rule 9), rejecting a token based on iat is optional and client-specific.

• Rationale is tied to front-channel replay protection

  • The purpose of iat validation is to bound the window for nonce replay attacks. This applies to front-channel flows (e.g., browser redirects), where responses may be intercepted and replayed.

In contrast, performTokenRequest handles back-channel responses, where:

• there is no intermediary capable of replaying the response
• the refresh token itself already provides session continuity guarantees

As a result, strict iat enforcement in refresh flows may not provide meaningful security benefits, while introducing real-world reliability issues on mobile devices with imperfect clocks.

Start by tracing ID Token iat validation from performTokenRequest and compare it with front-channel validation. Define a configurable policy or refresh-flow option while preserving strict validation by default; done means refresh responses can relax iat handling without weakening other checks and the behavior is covered by tests.