BankID i SaaS: flöden, fel och vad svenska team ofta missar

Om du bygger en SaaS-produkt i Sverige kommer någon – kund, partner eller er egen ledning – förr eller senare att fråga om BankID. Tekniskt handlar det ofta om att koppla samman BankIDs rekommenderade flöden med er egen domänmodell: användare, organisationer, roller och behörighet. Det som ser ut som en enda inloggningsknapp är i praktiken ett system av omdirigeringar, tillstånd, certifikat och felhantering som måste sitta hela vägen ut i kundsupporten.

Varför BankID inte är “bara OAuth”

Många team jämför intuitivt med social login. Skillnaden är att BankID bär på stark juridisk och operativ tyngd: användaren identifierar sig med en statligt sanktionerad e-tjänst, och er applikation måste respektera användarens avbrott, timeouts och avbrytanden utan att lämna systemet i ett halvautentiserat tillstånd. Det innebär att ni behöver en tydlig tillståndsmaskin på serversidan som vet skillnaden mellan “order skapad”, “påbörjad”, “lyckad” och “misslyckad”, och hur varje utfall mappas till er session eller tokenmodell.

I praktiken arbetar svenska webbappar ofta med BankID via leverantörer och bibliotek som kapslar in RP/API. Oavsett abstraktionsnivå måste ni dokumentera exakt vilken miljö ni kör mot (test vs produktion), vilka certifikat som gäller för er domän, och hur nycklar roteras utan downtime – särskilt om ni kör Kubernetes eller serverless där hemligheter sprids över flera instanser.

Flöde: order, redirect och “flicker” i SPA

Vanliga integrationer bygger på att servern skapar en order, skickar användaren till BankID-klienten eller Same Device-flödet, och tar emot callback med resultat. I en modern SPA-stack (t.ex. SvelteKit) uppstår ofta problem med dubbel navigation: användaren kommer tillbaka till en ruta som hinner renderas innan sessionen uppdaterats. Bygg därför alltid en dedikerad “retur-URL” som först validerar ordern serverside innan ni visar inloggat läge, och använd korta laddningstillstånd i UI som inte luras av mellanlägen i auth-cookien.

För B2B-SaaS tillkommer frågan om organisationstillhörighet. BankID bekräftar identitet, inte automatiskt vilken tenant användaren ska in i. Ni behöver en explicit kopplingsregel (inbjudan, domänmatchning, manuell onboarding) så att ni inte öppnar fel kunds data i samma ögonblick som personnumret verifieras.

Sessioner, cookies och API-anrop

Efter lyckad legitimering måste ni bestämma om ni använder server-side sessions, krypterade cookies eller tokens till ert API-lager. Min rekommendation för de flesta svenska B2B-produkter är att hålla BankID-resultatet nära servern: validera signaturer där ni redan har hemligheter, och ge klienten ett kortlivat sessionsbevis som kan återkallas centralt. Att sprida långlivade JWT:er till webbläsaren utan robust refresh- och revoke-strategi skapar snart incidentärenden när en enhet tappas eller en anställd lämnar bolaget.

Test: automation och persondata

BankID tillhandahåller testidentiteter och särskilda testmiljöer – använd dem konsekvent i CI, men var försiktig med att logga hela svarsobjekt i aggregatloggar. Personnummer och orderreferenser är personuppgifter även i test om de speglar verkliga format. Sätt rutiner för loggredaktion, retention och vem som får åtkomst till produktionsloggar när kunder rapporterar inloggningsproblem.

Checklista innan produktion

• Verifiera att retur-URL:er och tillåtna domäner matchar produktion.
• Säkerställ att order-ID inte kan återanvändas eller gissas av en angripare.
• Öva timeouts: vad händer om användaren stänger BankID-appen?
• Dokumentera felmeddelanden till support – många “buggar” är förväntade BankID-svar översatta till mänskligt språk.
• Planera bort tjänst: hur byter ni leverantör eller roterar certifikat utan att låsa ute kunder?

Bygger ni en produkt där BankID ska sitta tillsammans med AI-agenter, avtalsspårning eller komplex multi-tenant SaaS? På Avitus IT hjälper vi er att ta hela vägen från arkitektur till trygg produktion – baserade i Helsingborg, med erfarenhet av både offentliga och privata flöden.