Hvordan skal brugerne logge ind i jeres tjeneste?

Login er det første en bruger møder i din tjeneste og samtidig en af dens vigtigste sikkerhedsgrænser. Vælger du den forkerte metode, lukker du enten brugere ude med unødigt bøvl eller lukker de forkerte personer ind fordi det var for let. Det rigtige valg handler om at matche metoden med hvem der logger ind og hvor følsomme dataene er.

Metoderne: en sammenligning

Der findes ikke en universelt bedste loginmetode, kun den der passer til din situation. Her er de mest almindelige og hvad de er gode til.

Tabellen viser hvad hver af dem passer til, men et par nuancer er værd at tilføje. Socialt login sænker tærsklen markant, men binder dig til en ekstern udbyder som Google. Passkeys er alternativet uden adgangskode hvor enheden selv bekræfter identiteten: bekvemt og svært at ramme med phishing, og af mange set som vejen frem. E-mail og adgangskode er billigst at bygge, men lægger ansvaret på dig for at gemme adgangskoder sikkert og på brugeren for at huske dem.

Valget begynder med målgruppen. En bred forbrugertjeneste har fordel af socialt login eller engangskoder; en tjeneste der sælges til virksomheder, vil før eller siden få spørgsmålet om SSO.

Tofaktor efter datafølsomhed

Hvor stærkt du bør beskytte login, afgøres af hvad der står på spil hvis den forkerte person kommer ind. Det er dataenes følsomhed, ikke mavefornemmelsen, der skal styre.

Til et simpelt nyhedsbrev er tofaktorgodkendelse overdrevet. Det tilføjer friktion uden at beskytte noget værdifuldt. Til en tjeneste med betalinger, personoplysninger eller forretningskritisk information er det nærmest et must, for dér får en kapret konto reelle konsekvenser. En rimelig mellemvej for mange tjenester er at tilbyde tofaktor frivilligt til dem der ønsker det, og kræve det til de mest følsomme handlinger, f.eks. at ændre udbetalingsoplysninger.

Tænk i niveauer i stedet for alt eller intet: lav tærskel for at komme ind og læse, højere krav for at gøre noget følsomt. Så lægger du sikkerheden hvor der er brug for den, uden at straffe hvert eneste login.

Friktionens pris

Hvert ekstra trin i login og registrering koster dig brugere. Det er den ubekvemme sandhed der skal vejes op mod sikkerheden.

Et konkret eksempel: En webshop der tvinger kunden til at oprette en konto før købet, mister en del af kunderne netop dér. De ville handle, ikke blive medlemmer. Tilbydes der i stedet gæstekøb, gennemfører flere. Den samme logik gælder et unødigt strengt adgangskodekrav, et ekstra verifikationstrin eller en bekræftelsesmail der skal åbnes før man kommer videre. Hver af dem frasorterer nogen.

Kunsten er ikke at fjerne al friktion, men at placere den hvor den er begrundet. En følsom bankhandling tåler (og kræver) et ekstra trin. En tjeneste med lav følsomhed gør det ikke. Spørg for hvert trin: Beskytter det her noget der opvejer de brugere det koster? Hvis ikke, så fjern det.

Et scenarie fra beslutning til løsning

Lad os sige at I bygger en tjeneste hvor privatpersoner følger deres bookinger, og at I samtidig skal sælge en administrationsdel til erhvervskunder. To målgrupper, to forskellige svar. Begynd med de spørgsmål der styrer: Hvem logger ind? Hvor ofte vender de tilbage? Og hvad sker der hvis den forkerte person kommer ind?

For de privatpersoner der sjældent logger ind, bliver en engangskode eller socialt login en lav tærskel, uden adgangskode at glemme mellem gangene. For erhvervsdelen kommer spørgsmålet om SSO før eller siden. Kunderne vil have at medarbejderne logger ind med arbejdskontoen og at arbejdsgiveren styrer adgangen. Følsomheden afgør resten: Kan man kun læse sine egne bookinger, er en lav tærskel nok, men skal nogen ændre udbetalingsoplysninger, lægges der et tofaktortrin netop dér. Læg mærke til rækkefølgen: målgruppe og følsomhed først, metode bagefter.

En almindelig fejl

Den mest almindelige fejl er at sætte det samme sikkerhedsniveau for alt: enten en høj tærskel overalt “for en sikkerheds skyld” eller en lav tærskel overalt for ikke at miste brugere. Begge veje er forkerte. Kræver du tofaktor for at læse et nyhedsbrev, jager du folk væk uden at beskytte noget der er værd at beskytte. Nøjes du med adgangskode alene til en tjeneste med betalinger og personoplysninger, bliver en kapret konto en reel hændelse. En beslægtet fejl er at kræve en konto før brugeren har fået nogen værdi af tjenesten. Det er bedre at tænke i niveauer og lade indsatsen følge det der står på spil.

Hold også selve login adskilt fra det der ligger omkring det. At en bruger er logget ind (autentificering), er én ting; hvad vedkommende må se og gøre (autorisation), er noget andet. En almindelig bruger og en administrator kan logge ind på samme måde, men have forskellige rettigheder. Og kontohåndteringen ved siden af (at nulstille adgangskoden eller skifte e-mail) skal være mindst lige så sikker som login. Ellers bliver et svagt nulstillingsflow den lette vej ind.

Bygge selv eller bruge en tjeneste?

Et spørgsmål der ofte bliver glemt, er om I skal bygge login selv eller læne jer op ad en færdig identitetstjeneste. At bygge fra bunden giver fuld kontrol, men autentificering er et område hvor små fejl får store konsekvenser. Forkert lagring af adgangskoder eller et hul i nulstillingsflowet kan blive til en sikkerhedshændelse. Det er sværere at gøre rigtigt end det ser ud.

For de fleste tjenester er en etableret identitetsløsning derfor et klogt valg. Den kommer med sikker håndtering af adgangskoder, tofaktor, socialt login og ofte passkeys indbygget, og den vedligeholdes af nogen hvis hele opgave er at holde det sikkert. I betaler for tjenesten, men slipper for ansvaret for en af produktets mest følsomme dele. Det kan være begrundet at bygge selv ved helt særlige krav, men udgangspunktet bør være ikke at genopfinde login unødigt.

At afveje sikkerhed mod brugeroplevelse i login er præcis den slags afvejning vi hos Weapp laver i vores ydelser. Vil du have afklaret hvilken loginløsning der passer til din tjeneste og dine data? Kontakt os, så gennemgår vi mulighederne.