JWT Expiration vs. Embedded Refresh Token: Which Approach Yields Clearer Error Handling?

Goal

Enforce least‑privilege access and gracefully handle expired JWTs in a Ktor 2.x application.

Unresolved Decision

When a request arrives with an expired access token, should the application:

• Option A: Rely on the JWT verifier’s built‑in exp validation, then perform a custom verify lambda that checks roles and optionally initiates a refresh flow via a separate OAuth2 endpoint.
• Option B: Embed a refresh token as a claim in the same JWT and validate it in a second authentication pipeline that can issue a new access token without an external endpoint.

Constraints & Uncertainty

Both approaches are documented in the Ktor Authentication plugin, but their interaction with nested authenticate blocks and provider ordering remains unclear. The plugin’s onAuthenticationFailed callback can customize responses, yet its behavior when a provider’s token is expired and the pipeline falls through to the next provider is not fully specified.

Specific Questions

1. When an access token is expired, how does provider ordering affect the HTTP status code returned by Ktor’s authentication pipeline?
2. What are the security trade‑offs of embedding a refresh token as a claim versus exposing a dedicated OAuth2 refresh endpoint?
3. How can the Ktor TestEngine be used to simulate a token‑expiration scenario and verify that the chosen approach correctly triggers a refresh flow or returns an appropriate error?