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]

Reply via email to