Hur ska användarna logga in i er tjänst?

Inloggningen är det första en användare möter i din tjänst, och samtidigt en av dess viktigaste säkerhetsgränser. Väljer du fel metod stänger du antingen ute användare med onödigt krångel, eller släpper in fel personer för att det var för enkelt. Rätt val handlar om att matcha metoden mot vem som loggar in och hur känslig datan är.

Metoderna: en jämförelse

Det finns ingen universellt bästa inloggningsmetod, bara den som passar din situation. Här är de vanligaste och vad de är bra på.

Tabellen fångar vad var och en passar för, men ett par nyanser är värda att lägga till. Social inloggning sänker tröskeln rejält men binder dig till en extern leverantör som Google. Passkeys är det lösenordsfria alternativet där enheten själv bekräftar identiteten – bekvämt och svårt att nätfiska, och av många sett som riktningen framåt. E-post och lösenord är billigast att bygga men lägger ansvaret på dig att lagra lösenord säkert och på användaren att minnas dem.

Valet börjar i målgruppen. En bred konsumenttjänst tjänar på social inloggning eller engångskoder; en tjänst som säljs till företag kommer få frågan om SSO förr eller senare.

Tvåfaktor efter datans känslighet

Hur starkt du bör skydda inloggningen avgörs av vad som står på spel om fel person kommer in. Det är känsligheten i datan, inte magkänslan, som ska styra.

För ett enkelt nyhetsbrev är tvåfaktorsautentisering överdrivet – det lägger friktion utan att skydda något värdefullt. För en tjänst med betalningar, personuppgifter eller affärskritisk information är det närmast ett måste, eftersom ett kapat konto då får verkliga konsekvenser. En rimlig medelväg för många tjänster är att erbjuda tvåfaktor frivilligt för den som vill, och kräva det för de känsligaste åtgärderna – att ändra utbetalningsuppgifter, till exempel.

Tänk i nivåer i stället för allt-eller-inget: låg tröskel för att komma in och läsa, högre krav för att göra något känsligt. Då lägger du säkerheten där den behövs utan att straffa varje inloggning.

Friktionens pris

Varje extra steg i inloggning och registrering kostar dig användare. Det är den obekväma sanningen som måste vägas mot säkerheten.

Ett konkret exempel: en webbutik som tvingar kunden att skapa ett konto innan köp tappar en del av dem just där – de ville handla, inte bli medlemmar. Erbjuds gästköp i stället slutför fler. Samma logik gäller ett onödigt strikt lösenordskrav, ett extra verifieringssteg eller en bekräftelse-e-post som måste öppnas innan man kommer vidare. Var och en sållar bort någon.

Konsten är inte att ta bort all friktion, utan att lägga den där den är motiverad. Ett känsligt bankärende tål – och kräver – ett extra steg. En lågkänslig tjänst gör det inte. Fråga för varje steg: skyddar det här något som är värt de användare det kostar? Om inte, ta bort det.

Ett scenario från beslut till lösning

Säg att ni bygger en tjänst där privatpersoner följer sina bokningar och samtidigt ska sälja en administrationsdel till företagskunder. Två målgrupper, två olika svar. Börja i frågorna som styr: Vilka loggar in? Hur ofta återkommer de? Och vad händer om fel person kommer in?

För privatpersonerna som loggar in sällan blir en engångskod eller social inloggning en låg tröskel – inget lösenord att glömma mellan gångerna. För företagsdelen kommer frågan om SSO förr eller senare, eftersom kunderna vill att anställda loggar in med jobbkontot och att arbetsgivaren styr åtkomsten. Känsligheten avgör resten: kan man bara läsa sina egna bokningar räcker en låg tröskel, men ska någon ändra utbetalningsuppgifter läggs ett tvåfaktorssteg just där. Lägg märke till ordningen – målgrupp och känslighet först, metod sedan.

Ett vanligt misstag

Det vanligaste felet är att sätta samma säkerhetsnivå för allt: antingen en hög tröskel överallt “för säkerhets skull”, eller en låg överallt för att inte tappa användare. Båda blir fel. Kräver du tvåfaktor för att läsa ett nyhetsbrev jagar du bort folk utan att skydda något värt att skydda. Nöjer du dig med enbart lösenord för en tjänst med betalningar och personuppgifter blir ett kapat konto en verklig incident. Ett näraliggande misstag är att tvinga fram ett konto innan användaren fått någon nytta av tjänsten. Bättre är att tänka i nivåer och låta insatsen följa vad som står på spel.

Håll också isär själva inloggningen från det som ligger runt om. Att en användare är inloggad (autentisering) är en sak; vad den får se och göra (behörighet) är en annan – en vanlig användare och en administratör kan logga in likadant men ha olika rättigheter. Och kontohanteringen intill – att återställa lösenord eller byta e-post – måste vara minst lika säker som inloggningen, annars blir ett svagt återställningsflöde den enkla vägen in.

Bygga själv eller använda en tjänst?

En fråga som ofta glöms är om ni ska bygga inloggningen själva eller luta er mot en färdig identitetstjänst. Att bygga från grunden ger full kontroll, men autentisering är ett område där små misstag får stora konsekvenser – felaktig lösenordslagring eller en lucka i återställningsflödet kan bli en säkerhetsincident. Det är svårare att göra rätt än det ser ut.

För de flesta tjänster är därför en etablerad identitetslösning ett klokt val. Den kommer med säker lösenordshantering, tvåfaktor, social inloggning och ofta passkeys inbyggt, och underhålls av någon vars hela uppgift är att hålla det säkert. Ni betalar för tjänsten men slipper ansvaret för en av produktens känsligaste delar. Att bygga eget kan vara motiverat vid mycket speciella krav, men utgångspunkten bör vara att inte återuppfinna inloggningen i onödan.

Att väga säkerhet mot användarupplevelse i inloggningen är precis den sortens avvägning vi på Weapp gör i våra tjänster. Vill du reda ut vilken inloggningslösning som passar din tjänst och din data? Hör av dig så går vi igenom alternativen.