ForwardAuth middleware missing native token expiry validation

Traefik's ForwardAuth middleware delegates authentication to an external service and relies on that service to return HTTP 2xx with optional user-info headers before allowing a request to reach the backend. The middleware does not inspect or validate the contents of tokens—such as JWT expiry, audience, or scope claims—that are forwarded in request headers; it treats the external service's status code as the sole access decision.

This leaves an unresolved configuration boundary for least-privilege authentication. When the external auth service returns a 2xx response for an expired or insufficiently scoped credential, Traefik forwards the request to the backend without additional checks. Operators must decide whether to enforce token freshness and scope constraints entirely within the auth service, or whether Traefik offers any native mechanism to reject expired credentials before forwarding.

What configuration pattern enforces JWT expiry and scope validation when using ForwardAuth? Does Traefik provide any native mechanism to reject expired credentials before forwarding requests to the backend?