Workflow: User loads http://localhost:5000
Absolutely, this is a great “let’s debug like a pro” moment.
Here’s what’s happening, line by line, as you walk back to your PC and reload:
1. You Reload the Page
-
Your browser tries to load the home page (
/) of the API Gateway.
2. Gateway Checks Your Auth Session
-
The API Gateway checks if you have a valid session (i.e., an
id_tokenstored in the Flask session cookie). -
It finds an existing JWT token from before you left (from earlier today).
3. It Tries to Verify the JWT
-
The function
verify_id_token()is called. -
It decodes the token and prints the claims:
Decoded claims: { 'iss': 'https://aurorahours.com/identity-backend', 'sub': 'username', 'aud': 'browser-ui', 'iat': 1754206747, 'exp': 1754207647, 'scope': 'openid' } -
The exp (
expclaim) is in the past (token is expired). -
It calculates and logs:
Token expired at 2025-08-03T07:54:07Z, issued at 2025-08-03T07:39:07Z, now=2025-08-03T08:35:27Z
Why?
-
The
id_tokenwas issued at 7:39 UTC and expired at 7:54 UTC. -
You’re now at 8:35 UTC (i.e., you’ve been away >40 minutes).
-
Your session cookie is still present, but the JWT is expired.
4. The App Handles the Expired Token
-
verify_id_token()raises an exception: “ID token expired”. -
The error is logged:
ERROR API Gateway - [verify_id_token] JWT verification failed: ID token expired WARNING API Gateway - ID token validation failed: Invalid token: ID token expired -
As a result, your session is cleared (logged out), and the app redirects you to login again.
5. You See a Redirect to Login
-
The Gateway triggers a fresh login flow:
Redirecting to OIDC auth: state=31ac223c-0321-4fb1-9ea4-72415f3bc37e, ... -
Browser gets bounced to the OneLogin/OIDC page at identity-backend’s
/authorize.
6. DeprecationWarnings
-
These are about how you’re converting Unix timestamps to UTC.
-
Python wants you to use:
datetime.fromtimestamp(exp, datetime.UTC)instead of:
datetime.utcfromtimestamp(exp) -
This is just a heads-up for future Python versions—not a functional error, but clean it up soon.
7. Flow Summary:
What happened?
-
Your old token was expired when you came back.
-
App detected this and gracefully redirected you to log in again.
-
You were shown the (beautiful!) OneLogin page.
-
Logs show all the steps and errors—no mystery, and this is exactly what should happen.
Principal Engineer Takeaway
-
This is exactly how session/JWT expiration should be handled.
-
Session persistence does not mean you’re still authorized—JWT expiry keeps you secure.
-
Logs and errors are clear and actionable—no user sees a raw traceback.
-
The warnings are for future-proofing code; they don’t block you, but update the timestamp code soon.
Want help fixing the DeprecationWarnings? Or want a “session expiry UX” improvement, like a “Session expired, please log in” message instead of just redirecting?
Comments
Post a Comment