JWT-autentisering går sönder i de tråkiga detaljerna. Tokens hamnar i localStorage, XSS blir ett kontoövertagande och refresh-flöden blir en hög av edge cases som ingen övervakar. Sedan skeppar du ”tillräckligt bra” autentisering och spenderar nästa kvartal med att jaga märkliga utloggningsbuggar och misstänkta replays.
Den här cookie-baserade JWT-autentiseringen är byggd för produktingenjörer som behöver ett säkert inloggning/refresh/utloggningsflöde som inte läcker tokens till webbläsarens JavaScript, tech leads som måste standardisera middleware och cookie-policyer över flera tjänster, och säkerhetsmedvetna grundare som vill ha en praktisk plan inför ett penetrationstest. Resultatet är ett design-dokument i produktionsklass med implementationsmönster (cookies, headers, rotationsregler, middleware-struktur) plus loggning och övervakningssignaler som du faktiskt kan koppla in.
Vad gör den här AI-prompten och när ska du använda den?
| Vad den här prompten gör | När du ska använda den här prompten | Vad du får |
|---|---|---|
|
|
|
Hela AI-prompten: cookie-baserat JWT-autentiseringsflöde i produktionsklass
Fyll i fälten nedan för att anpassa prompten efter dina behov.
| Variabel | Vad du ska ange | Anpassa prompten |
|---|---|---|
[APPLIKATIONSTYP] |
Ange vilken typ av applikation du arbetar med, till exempel webb, mobil eller desktop, och inkludera relevanta detaljer om funktionalitet och hur användare interagerar med den. Till exempel: "En single-page webbapplikation för e-handel, byggd med React och som integrerar mot REST-API:er."
|
|
[NUVARANDE_TEKNIKSTACK] |
Beskriv vilka ramverk, runtime-miljö, hostingupplägg och reverse proxy-konfiguration som applikationen använder i dag. Till exempel: "Node.js-backend med Express, driftad på AWS Lambda med en NGINX reverse proxy framför."
|
|
[SAKERHETS_ELLER_EFTERLEVNADSKRAV] |
Beskriv vilka specifika säkerhets- eller efterlevnadsstandarder applikationen måste uppfylla, till exempel SOC2, HIPAA, PCI eller GDPR. Till exempel: "Applikationen måste följa GDPR för hantering av användardata och SOC2 för operativa säkerhetskrav."
|
|
[ONSKAD_SESSIONSLANGD] |
Ange önskad sessionslängd, inklusive både inaktivitets-timeout och absolut utgångstid, för att kunna definiera token-livslängder. Till exempel: "Inaktivitets-timeout på 15 minuter och absolut sessionstid som löper ut efter 24 timmar."
|
|
[BEFINTLIGA_AUTENTISERINGSPROBLEM] |
Beskriv eventuella observerade sårbarheter eller problem i nuvarande autentiseringslösning, till exempel tokenstöld, sessionskapning eller bristfällig utloggningshantering. Till exempel: "Tokens som lagras i localStorage är sårbara för XSS-attacker, och sessionskapning har observerats på grund av saknat CSRF-skydd."
|
Proffstips för bättre resultat med AI-prompten
- Ange klienttyp och API-topologi. Berätta för prompten om du har en SPA som anropar en separat API-domän, en monolit eller en BFF (backend-for-frontend). Lägg till en rad som: ”Frontend: Next.js på app.example.com, API: api.example.com bakom ALB” så att cookie-domän/path och CORS/CSRF-detaljer blir korrekta.
- Be om en konkret cookie-matris. Efter första svaret, följ upp med: ”Ge mig de exakta cookie-namnen, flaggor, domän/path-scope och max-age för access-, refresh- och CSRF-cookies.” Det tvingar fram specifika värden i stället för allmänheter och gör implementationsgranskningar enklare.
- Tvinga återanvändningsdetektering och hantering av utloggningsraces. Många designer hoppar över detta, och ärligt talat är det här verkliga incidenter bor. Prompt: ”Inkludera refresh token-rotation med återanvändningsdetektering, och förklara vad som händer när en stulen refresh används efter att den legitima klienten redan har roterat.”
- Iterera på felbeteende, inte bara säkerhet. När du fått det säkra flödet, be: ”Skriv nu om de klient-synliga felen och retry-reglerna för att undvika oändliga refresh-loopar; inkludera exempel för svaren 401 vs 403 vs 419 (CSRF).” Målet är en säker och lugn UX.
- Gör det operativt genom att be om loggscheman. Lägg till: ”Ge ett JSON-loggexempel för inloggning, refresh, refresh-nekad (replay) och utloggning, inklusive fält som user_id, session_id, token_family_id, ip_hash, user_agent_hash och reason codes.” Det gör en design till något ditt SIEM kan använda.
Vanliga frågor
Backendingenjörer använder den här för att göra ”använd HttpOnly-cookies” till ett faktiskt flöde med middleware, rotation och ogiltigförklaring på serversidan. Frontendansvariga vinner på att designen håller UI:t fritt från tokenlagring och refresh-logik, vilket minskar skör klientkod och märkliga edge cases. Säkerhetsingenjörer använder den för att hotmodellera vanliga exploit-vägar (XSS-stöld, replay, session fixation) och verifiera kontroller som CSRF-skydd och återanvändningsdetektering. Ingenjörschefer använder leveransen som referens för utrullning så att flera tjänster implementerar samma cookie-flaggor, felbeteende och loggfält.
SaaS-bolag får värde eftersom multi-tenant-appar ofta möter strikta säkerhetsenkäter, och en dokumenterad cookie-baserad JWT-approach med rotation och övervakning besvarar dem tydligt. E-handelsvarumärken gynnas när checkout- och kontoområden ofta är XSS-mål; att hålla tokens borta från JavaScript minskar skadeomfånget vid en frontend-bugg. Fintech och reglerade produkter använder den för att linjera sessionshantering med compliance-förväntningar som tydligt utloggningsbeteende, session ogiltigförklaring och revisionsvänliga loggar. Byråer som bygger webbplattformar åt kunder kan standardisera en auth-baslinje över projekt, vilket gör leverans snabbare och minskar risken med ”specialbyggd auth”.
En typisk prompt som ”Skriv ett säkert JWT-auth-system med cookies” misslyckas eftersom den: saknar konkreta regler för rotation och återanvändningsdetektering, ger ingen middleware-struktur för verifiering och koppling av användarkontext, ignorerar CSRF-mekanik som är obligatorisk när cookies används för autentisering, producerar vaga råd som ”sätt HttpOnly och Secure” i stället för exakta cookie/header-mönster, och missar operativ vägledning som loggfält och larmbara signaler. Du får något som låter säkert men faller isär vid replay, utloggningsraces och verkliga angriparflöden.
Ja. Det snabbaste sättet är att lägga till dina miljödetaljer först (SPA vs server-renderad, en domän vs subdomäner, mobilklienter och om du har en gateway/proxy som terminerar TLS). Be sedan om stack-specifik output, till exempel: ”Anta Node/Express + Next.js bakom Cloudflare; ge cookie Domain/Path, SameSite-val, CSRF-header-mönster och middleware-pseudokod.” Om du har ovanliga begränsningar (cross-site embeds, tredjeparts-IdP, flera API:er), säg det direkt och be om ”säkra standardval” plus alternativa val med avvägningar.
Det största misstaget är att lämna deployment-topologin vag—i stället för ”en webbapp”, säg ”SPA på app.example.com som anropar api.example.com med credentials inkluderade.” Ett annat vanligt fel är att inte be om explicit CSRF-hantering; ”vi använder cookies” räcker inte, så be om ett specifikt double-submit- eller origin/CSRF-header-mönster och när det ska enforced. Team glömmer också att kräva detaljer för refresh-rotation, vilket leder till refresh-tokens som går att återspela; be om ”rotation plus återanvändningsdetektering på serversidan” och vad som händer vid återanvändning. Slutligen hoppar många över övervakningsoutput; kräv en lista med loggfält och exempel på events så att du kan upptäcka refresh-stormar, toppar i ogiltiga signaturer och misstänkta geo-/IP-förändringar.
Den här prompten passar inte optimalt för team som behöver en minimal demo med en enda endpoint och inte tänker implementera rotation, ogiltigförklaring och övervakning. Den är också ett dåligt val om din produkt strikt är icke-webbläsarbaserad (till exempel machine-to-machine-API:er) där cookies och CSRF helt enkelt inte är rätt verktyg. Och om du inte har validerat grundkrav som sessionens varaktighet, regler för enhetstillit eller utloggningsförväntningar kan designen kännas för ”tung” för tidigt. I de fallen: börja med att dokumentera krav och hotmodellens omfattning, och kom sedan tillbaka till den här prompten för versionen i produktionsklass.
Autentisering är antingen lugn eller kaotisk. Den här prompten hjälper dig att designa den lugna versionen, med cookies, CSRF-skydd, rotation och övervakning tydligt beskrivna så att du kan implementera med trygghet.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.