BankID i webb och app: flödena som avgör om användaren kommer in

Själva anropet mot BankID är inte det svåra. Du startar en order, visar en QR-kod eller växlar över till appen, frågar efter status tills svaret kommer och släpper in användaren. Så långt är det rakt fram.

Sedan möter flödet verkligheten. Telefonen ligger i jackan i hallen. Användaren har två flikar öppna. Ordern hinner gå ut innan appen har startats. Någon försöker logga in från en lånad dator. Det är där det avgörs om användaren kommer in eller ger upp.

Tre flöden, inte ett

Det vanligaste misstaget är att bygga ett flöde och hoppas att det täcker alla. Räkna med tre, och bestäm tidigt vilka du behöver:

• Samma enhet. Användaren är på mobilen. Du växlar över till BankID-appen och tillbaka igen. Testa att användaren verkligen kommer tillbaka till rätt ställe, för det beter sig olika i olika appars inbyggda webbläsare.
• Annan enhet. Användaren sitter vid datorn och läser av en QR-kod med telefonen. Här gör den animerade QR-koden sitt jobb.
• BankID på telefon. Ett ombud startar legitimeringen under ett samtal och användaren legitimerar sig i sin app, utan att någon kod behöver läsas upp. Har du kundtjänst är det oftast det här flödet som saknas. Det har ett eget anrop i API:et och egna villkor, så läs på innan du lovar det.

Bygger du bara ett blir det nästan alltid ”annan enhet”, eftersom det är enklast att testa från en utvecklardator. Det är också det flöde som är krångligast för den som redan sitter i mobilen: du kan inte läsa av en QR-kod på din egen skärm.

Den animerade QR-koden är inte kosmetik

En statisk QR-kod går att fotografera och skicka vidare. Så har bedrägerier gått till: bedragaren startar en inloggning, skickar QR-koden till offret och får offret att läsa av den. Sedan är bedragaren inne som offret. Därför räknas QR-koden om varje sekund ur ett hemligt värde du fick när ordern skapades, och BankID har slutat stödja statiska koder.

Tre saker följer av det:

• Hemligheten stannar på servern. Servern räknar fram QR-datan och skickar den till webbläsaren, som bara ritar koden.
• Koden byts i takt med klockan, inte i takt med att din statusfråga råkar svara.
• Den ska aldrig cachas, skärmdumpas eller mejlas som ett supportknep.

App-växlingen på mobil

På samma enhet startar du appen med en engångstoken och talar om vart användaren ska tillbaka. Utelämnar du återhoppet kan användaren bli kvar i BankID-appen efter legitimeringen, utan att veta om det gick bra. Och att användaren kommer tillbaka betyder inte att det gick bra: kontrollera resultatet på servern innan du släpper in någon.

Testa också när sidan öppnas i en annan apps inbyggda webbläsare, till exempel från en länk i ett socialt flöde eller i ett mejl. Det är där app-växlingen oftast går sönder, och det märker du sällan innan en kund hör av sig.

Hjälp användaren vidare efter ett avbrott

BankID svarar med en status och en ledtråd om varför det står still. Ledtrådarna är skrivna för utvecklare, inte för användare. Ditt jobb är att översätta varje ledtråd till en mening och en väg framåt.

• Appen har inte tagit emot ordern. Skriv ”öppna BankID-appen” i klartext, inte kodnamnet från API:et. På annan enhet: be användaren läsa av QR-koden och håll den läsbar medan du väntar. På samma enhet: visa en knapp som startar appen igen.
• Appen startade inte (samma enhet). Erbjud att försöka igen, och erbjud annan enhet som alternativ i stället för att låta användaren stå och undra. Det behöver inte betyda att appen saknas, bara att den inte startade den här gången.
• Användaren avbröt. Bekräfta att inloggningen avbröts och erbjud att börja om. Visa det inte som ett fel.
• Ordern gick ut. Den som inte hann hämta telefonen ska kunna börja om med ett klick, inte skickas tillbaka till inloggningssidan. På annan enhet betyder det en ny QR-kod, på samma enhet en ny app-start.
• Legitimeringen misslyckades. Var sparsam med detaljer av säkerhetsskäl, men säg alltid hur användaren kan gå vidare.

En order lever inte för evigt. Hinner användaren inte fram i tid är den borta, och då ska det gå att börja om direkt där man står. Bygg omstarten som en vanlig del av gränssnittet, inte som ett felmeddelande i rött.

Att anropet fungerar betyder inte att inloggningen gör det. Bygg för avbrotten också.

Två flikar, två ordrar

Användaren öppnar en flik till och startar en ny order. Nu pågår två legitimeringar samtidigt, och frågan är vilken som hör till sessionen. Ligger svaret i webbläsaren har du ett fel som är svårt att felsöka och obehagligt att ha kvar.

Låt servern äga ordern. Knyt varje order till sessionen, avbryt den föregående när en ny startas, och lita aldrig på att klienten talar om vilken som gäller. Kontrollera resultatet på servern innan du släpper in någon. Det är inte hela säkerhetsmodellen, men börja där.

Signering är inte inloggning

Vid en signering räcker det inte att spara att användaren sa ja. Spara det användaren skrev under, alltså exakt den text som visades och skickades in i ordern, tillsammans med signaturen och spärrkontrollsvaret. Kontrollera signaturen och spärrkontrollsvaret när de kommer in. Att bara spara dem bevisar ingenting.

Kan du ta fram exakt den text som visades om någon bestrider avtalet om fem år? Ett ”ja” i en databaskolumn klarar inte det. Spara texten, signaturen och kontrollsvaret tillsammans, i ett format du fortfarande kan öppna. Hur länge du måste spara det är en juridisk fråga, inte en teknisk.

Så testar du utan skarpa legitimationer

Skriv först tester för din egen tillståndshantering med simulerade svar: avbryt mitt i, låt ordern gå ut, starta två ordrar samtidigt. Kör sedan flödet mot BankID:s testmiljö, som har egna testlegitimationer. Testa till sist app-växlingen för hand på riktiga telefoner.

Skriv de fallen en gång. Att klicka igenom dem för hand inför varje release är det ingen som kommer ihåg, och det är precis de som går sönder när något annat ändras.

Vi bygger BankID-integrationer och tar hand om avbrotten. Vid signering ser vi till att underlaget sparas. Så jobbar vi med BankID. Ska tjänsten ta betalt med Swish är det en integration till att planera. Och skriv kontraktet före koden här som överallt annars.