Opaque sessions & instant revocation
The gateway demo keeps
the JWT in the browser and says so. This is the alternative: the browser holds only an opaque
session_id, the real tokens live in Redis, and
the project's own session-service brokers every
request. The whole point you can feel below: revocation is instant, not "eventually, when the token expires."
Log in and the browser receives only an opaque session_id — the JWT and refresh token stay in Redis, server-side. Every request goes through/bff-api/*, which the gateway resolves against session-service before proxying. Then log out and hit the endpoint again: it 401s immediately — no waiting for a token to expire, because the server-side session is simply gone.
1. Log in (opaque session)
2. Call → log out → call again
The proof: call once (200), log out, then call the same endpoint again — it returns 401 on the very next request. Compare with the gateway demo, where a logged-out JWT keeps working until it expires.
Request Log
No requests yet.
- What it costs
- An extra network hop and a stateful session store (Redis) on the request path — the gateway resolves every call against session-service. More moving parts than a stateless JWT.
- When you'd choose differently
- Reach for the plain gateway pattern when statelessness and one less hop matter more than instant revocation, or for pure service-to-service traffic where there's no browser to protect. The BFF cost earns its keep when XSS is a real threat or you need to kill a session the moment someone clicks log out.