GayathriSrividya commented on code in PR #67944:
URL: https://github.com/apache/airflow/pull/67944#discussion_r3354025115
##########
airflow-core/src/airflow/api_fastapi/execution_api/app.py:
##########
@@ -141,7 +148,18 @@ async def dispatch(self, request: Request, call_next):
try:
async with svcs.Container(request.app.state.svcs_registry) as
services:
validator: JWTValidator = await services.aget(JWTValidator)
- claims = await validator.avalidated_claims(token, {})
+ try:
+ claims = await validator.avalidated_claims(token, {})
+ except pyjwt.ExpiredSignatureError:
+ # Token may have expired between the auth check and
here
+ # (e.g. token lifetime boundary crossed during request
+ # processing). Re-validate with a short grace period so
+ # the client receives a fresh replacement token and can
+ # retry automatically. The signature and all other
+ # claims are still fully verified.
+ claims = await validator.avalidated_claims(
+ token, {}, extra_leeway=self.REISSUE_GRACE_LEEWAY
+ )
Review Comment:
Thanks, this is a fair concern. You’re right that adding any extra leeway
during reissue is not acceptable, so I’ve removed that approach.
The root cause here is a time-of-check/time-of-use gap:
Token is validated during auth dependency resolution near request start.
Reissue logic runs after handler execution.
If the request crosses the expiry boundary in between, a second validation
at reissue time can fail, even though the request was legitimately
authenticated at entry.
So the fix is to stop re-validating in reissue middleware and instead reuse
the already-validated token claims produced by JWTBearer for that same request.
This preserves strict expiry validation semantics and avoids a second,
inconsistent validation pass. No extra leeway is used.
On the 80% point: reissuing at 80% helps most flows, but it cannot prevent
failures when a request starts before the threshold and finishes after expiry
(for example, a slow request near token end-of-life). Reusing cached validated
claims removes that race.
Also, from what I can see in your current PR diff, you already switched
middleware to use JWTBearer-cached claims, which is correct. One remaining
cleanup is still needed:
Remove the extra_leeway parameter additions from JWT validator methods
entirely, since they are now unused and were the insecure part reviewers
objected to.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]