BankID till WordPress

Läget

Kunden hade redan BankID i sin app. Där loggar medlemmen in med BankID mot organisationens egna molnfunktioner, som i sin tur pratar med GrandID. På webben fanns inget av det. Samma person hade en identitet i appen och en helt annan på sajten, och det är inte bara opraktiskt — det är två register att hålla i synk för all framtid.

Varför ingen färdig koppling dög

Det finns färdiga WordPress-plugins för BankID, och de fungerar bra för det de är gjorda för: att autentisera någon mot WordPress egen användartabell. Här hade det gett exakt det problem vi ville bli av med — ytterligare en identitetskälla vid sidan av den som redan är facit. Dessutom hade lösningen krävt att kunden själv tecknade avtal med leverantören, med startavgift och en löpande månadskostnad, för något de redan betalar för i appen.

Vi valde i stället att gå samma väg som appen: mot kundens egna funktioner för inloggning och session, som äger kontakten med GrandID. En identitetskälla, ett flöde, ett ställe att felsöka.

Vad vi byggde

Inloggningen ligger bakom ett provider-gränssnitt med två lägen — ett mockläge med fasta testdata och ett skarpt läge mot kundens miljö. Hela flödet går att köra igenom, inklusive felfall, utan att någon behöver ta fram sitt riktiga BankID för varje test.

Utöver ren inloggning täcker flödet aktivering, alltså när en befintlig medlem ska få ett konto på webben för första gången, byte av företag för den som representerar flera, och att lägga till personer under ett företagskonto. Det är olika flöden med olika regler, och de går inte att slå ihop till en knapp.

Vad det gav

Samma identitet i appen som på sajten. Inget lösenord att glömma, inget separat konto att administrera, och ingen andra uppsättning personuppgifter att skydda. För organisationen blev det dessutom en kostnad mindre att ta ställning till.