What this prompt does
This prompt forces an opinionated decision between JWT bearer tokens, signed session cookies, or a hybrid — backed by a threat model rather than a both-are-fine shrug. The model compares XSS, CSRF, token theft, and replay for each option, then designs the part JWTs usually fumble: logout and revocation. It covers token lifetime strategy, gives an implementation sketch in your stack, lists pitfalls, and ends with a clear recommendation and reasoning.
The variables tailor the call to your situation. [app_shape] (say, a web SPA plus a mobile app) determines which threats and clients matter. [requirements] is the deciding input — listing hard needs like instant logout, a device list, and a refresh flow constrains the answer, because stateless tokens cannot truly revoke without a server-side check. [stack] makes the implementation sketch concrete in your actual backend and frontend rather than generic.
When to use it
- You are choosing an auth strategy for a SPA, mobile app, or both
- Instant logout or session revocation is a hard requirement
- You need the XSS, CSRF, theft, and replay tradeoffs laid out per option
- You want the revocation story designed before the token format is chosen
- You need a token-lifetime plan: access versus refresh, rotation, device list
- You want an implementation sketch in your specific stack, not abstract advice
Example output
The model returns a comparison table covering XSS, CSRF, token theft, and replay for JWT, session cookie, and hybrid, then a logout and revocation analysis, a token-lifetime strategy, and a stack-specific implementation sketch for the recommended option. It closes with a list of pitfalls to avoid and a single clear call — JWT, session cookie, or hybrid — with the reasoning tied back to your requirements.
Pro tips
- List every hard need in
[requirements]; instant logout in particular tends to decide the answer toward session cookies or a hybrid - Describe
[app_shape]fully — a mobile client changes the CSRF and token-storage tradeoffs versus a browser-only SPA - Set
[stack]to your real backend and frontend so the implementation sketch is usable, not generic - Make the model design the revocation path first; stateless tokens cannot truly revoke without a server-side check
- Heed the pitfalls section — long-lived JWTs in localStorage, silent refresh races, and clock skew are the usual traps
- If you need a device list or refresh rotation, confirm the recommended option actually supports them before committing
- Ask the model to spell out the refresh-token rotation flow step by step, since silent refresh races are a common source of subtle auth bugs
- For a hybrid recommendation, make sure the comparison table explains exactly which client uses which mechanism, so the split is intentional and not accidental
