Varför du inte borde bygga ditt eget autentiseringssystem: lärdomar från dussintals kundintervjuer

Autentisering ser ut som något du snabbt kan fixa själv. E-post, lösenord, hashning, jämför vid inloggning. Hur svårt kan det vara att bygga sitt eget autentiseringssystem?

Du kan. Det är fällan.

Vi har pratat med dussintals team om auth-system som de byggt själva. De flesta kom till oss av samma orsak: det höll verksamheten tillbaka.

Olika branscher, tekniker och storlekar, men samma slut. Auth-systemen de byggt hade blivit en teknisk skuld för teamet.

Det märkliga är att det aldrig visar sig som ett driftstopp. Systemet loggar in folk och fungerar fint – tills en verksamhetsförändring blockerar vägen: en säkerhetsgranskning, den första företagskunden, ett förvärv, en funktion som spänner över två produkter.

Förra veckan var det "okej". Nästa punkt på planen fastnar bakom det.

Det största misstaget med hemmabyggd auth är att behandla det som en funktion. Du kan koda det dag ett. Men när riktig trafik strömmar genom det, trasslar det in sig med dina användare, organisationer och behörigheter.

Autentisering är ingen funktion. Det är identitetsinfrastruktur.

Bakom inloggningssidan finns en hel identitetsmodell#

Varje hemmabyggt auth-system börjar likadant. Ta en e-postadress och ett lösenord, hashning, lagra, jämför vid inloggning. Fyrtio rader kod, rent och klart.

Problemen börjar efter lanseringen. Botar bombarderar registrerings-endpointen, så du lägger till rate-limiting, CAPTCHA, device-fingerprinting. SMS-koder slutar gå ut en morgon, så du bygger in retries och en daglig gräns. Sedan kommer de svårare delarna: säker lösenordsåterställning, MFA och recovery-flöde, sessioner och refresh tokens, och en behörighetsmodell som är mycket mer än en is_admin-boolean.

Inget av detta är svårt i sig. Varje grej ryms i en sprint. Men varje gång du levererar en så svarar du på en större fråga för produkten.

Stapla dessa svar, och du får den identitetsmodell som din produkt nu tyst antar är sann: vem räknas som användare, om en person kan tillhöra flera organisationer, hur en företagskunds egen identitetssystem kopplas in, och hur åtkomst återkallas när någon slutar.

Varje funktion du skriver därefter tar dessa svar för givna, och ju längre de består, desto svårare blir de att ändra.

Vi såg det här på ett företag: ett vertikal B2B SaaS, tjugo år i drift, för fysiska butiksägare. De byggde sin egen auth för över ett decennium sedan, med separat inloggning per kund och behörighetskontroller direkt i affärsmodulerna. Det var vettigt då.

Tjugo år senare ville de göra något som låter litet: en gemensam inloggningssida med e-post som användarnamn. Det var dock inte bara en sidändring. Kontrollerna fanns i hundratals moduler, och att ena inloggningen innebar att ändra användarmodellen, org-modellen, credentials-migrering och varje behörighetsgräns. Ingen ville godkänna det, så det drog ut på tiden flera år.

När de skrev den första inloggningssidan såg det ut som en funktion. Kvar blev en hel identitetsmodell.

När verksamheten trycker på, räcker ofta inte hemmabyggd auth längre#

För att vara rättvis: hemmabyggd auth brukar fungera länge. Det låter folk logga in, uppdaterar sessioner, och sköter verksamheten i åratal. Komplexiteten byggs upp långsamt, aldrig allt på en gång, och du hanterar det steg för steg medan du tror att du har koll.

Men att det "räcker" betyder ofta bara att företaget inte ännu har kört in i väggen. När det händer, är problemet sällan auth i sig. Det är verksamhetens behov som ändrats, och "räcker" blir "i vägen" över en natt.

Situationerna nedan dyker upp för de flesta produkter när de skalar. De ser olika ut, men under ytan är det samma sak: verksamheten tog ett steg, men den gamla identitetsmodellen hänger inte med.

Företagskunder börjar be om SSO#

Scenariot: en kund vill logga in via sitt eget IdP, och ditt auth-system har ingen aning om "någon annans identitetsleverantör."

Den första riktiga enterprise-affären landar och inköpsavdelningen skickar kravspec. Först är det SSO via Microsoft Entra eller Google Workspace. Sedan både SAML och OIDC, för nästa kund kör något annat. Sedan SCIM, för att provisionera och avprovisionera anställda automatiskt.

Varje kunds inställning är unik: olika protokoll, fältmappningar, certifikatrotation och sätt deras org-struktur mappas mot din.

Nästan inget arbete går att återanvända. Nästa kund har ett annat IdP och ny konfiguration, det mesta börjar om. SSO är ingen funktion du bygger en gång. Varje stor kund du skriver på kräver att du bygger om det, och kostnaden växer med antal kunder.

Auth är inte längre "låt användare logga in i din produkt." Nu är det "låt din produkt kopplas mot kundens identitetssystem." Två helt olika jobb.

Vi såg ett företag där hela SSO-uppsättningen sköttes för hand, och exakt en ingenjör förstod allt. När han var där gick kunder live. När han tog ledigt stod sälj och onboarding still. När han slutade försvann all kunskap med honom.

Inget av detta var på bordet dagen de valde bygga eget auth.

Produkten behöver ena splittrade identiteter#

Scenariot: din identitetsdata startade splittrad, uppdelad per org och produkt, och när verksamheten växer behöver du plötsligt en enhetlig identitet.

Företaget från exempel ovan råkade ut för detta vid försök att ena inloggningen, och mönstret återkommer för andra produkter. Vi jobbade med en plattform som hade nio produkter, alla via förvärv, var och en med sin egen auth och användardatabas.

Ett förvärv slår inte ihop dessa åt dig. Varje produkt du köper ger dig en ny auth-stack, och nio parallellt kräver verkligt personalbehov bara i underhåll.

Frågorna hopar sig. Är samma person en användare i produkt A och B, eller två? Hur matchar du samma kundorganisation tvärs båda? Hur auktoriserar du en tvärprodukt-funktion? När en anställd slutar, hur återkallar du åtkomst över alla nio? Och hur reviderar du något av det?

Ingen av de nio är trasig. Tillsammans är de en vägg.

"Ena identitet" låter som en funktion. I kod betyder det att omdefiniera det mest grundläggande som finns: vad som räknas som en användare och en organisation. Nästan varje funktion vilar på den gamla definitionen, så flyttar du den, flyttar du hela lagret ovanpå.

I AI-eran får agenter och CLI:s åtkomst för användarnas räkning#

Scenariot: det är inte längre bara folk som loggar in via en webbläsare. Nu agerar agenter, kommandorader och skript för någon användares räkning, medan din auth bara fattar en sak: folk som loggar in på en sida.

En agent måste ringa dina interna verktyg för en användare. En MCP-server ska exponera skyddade resurser säkert. En CLI ska komma åt kontodata utan webbläsare.

Alla tre brottas med samma frågor: vilken användare agerar denna begäran för, vilka resurser får den nå, till vem är token utställd, vad är dess scope, hur återkallar du den, och loggar du användaren eller agenten?

Det gamla systemet byggde aldrig de mekanismer dessa klienter behöver. MCP förutsätter OAuth för auktorisering. En CLI får gå via OAuth-inloggning eller bära ett personligt åtkomst-token som fungerar för en användare och kan återkallas när som helst. Inget av det var skapat för en inloggningssida.

Om din auth är byggd för en person på en webbsida är nu läget att hantera klienter som agerar för den personens räkning.

Långsiktigt underhåll är den största kostnaden med att bygga auth själv#

Ingen av situationerna ovan är "auth kraschade." Systemet snurrar fortfarande. Varje del ser ut som en liten funktion, men när du väl börjar handlar det om produktstrategi, datamigrering och leverans till kund.

MFA är det tydligaste exemplet. På ytan är det "kan vi verifiera en gång till efter inloggning."

Två steg in är frågorna: vilka orgs och användare ska tvingas använda det, kan en admin framtvinga det för medlemmar, krävs omverifiering för känsliga åtgärder som att byta betalningsinfo eller exportera data, hur genereras och återställs recovery-koder, kan support återställa dem, och tillhör en SSO-användares MFA dig eller kundens IdP? Att lägga till MFA betyder att lägga på ett helt lager säkerhetspolicy.

"Bara synka några användare" är samma visa: bakom det sitter en rad beslut om onboarding, offboarding och tvär-org-medlemskap – alla förutsätter att modellering av användare och organisationer var rätt från början.

Ju fler funktioner du lägger på, desto mer underhåller du en egen identitetsprodukt inuti din produkt. Första versionen är billig, några ingenjörer några veckor. Men du matar det år efter år.

Den dolda kostnaden: fakturan ändrade bara form#

Det vanligaste skälet till att bygga själv är kostnad, och det är inte naivt.

En medlemsorganisation vi intervjuade räknade på saken för fem år sedan. De hade cirka hundratusen medlemmar, men bara några tusen loggade in regelbundet. Leverantörer tog betalt per total antal medlemmar, offerten flög över budget, och att bygga själva blev billigare. För det året var det rätt val.

Fem år in hade siffrorna svängt. Att underhålla och säkra det egna systemet hade redan blivit dyrare än att köpa.

Första året är fakturan du slipper synlig och utvecklingstiden osynlig. Efter fem år är de undvikna fakturorna lika, men utvecklingstiden har blivit förseningar i roadmap, säkerhetsskuld och underhåll ingen vill ta över.

Att bygga eget auth är alltså inte gratis. Du får bara aldrig en faktura där det står "autentiseringsprenumeration." Du betalar med personmånader, missade deadlines, omarbeten, säkerhetsskuld och utvecklartid som kunde lagts på kärnprodukten.

En handfull ingenjörer äger det i slutändan#

Ingenjören som själv underhöll SSO:et är ingen engångsgrej. Kör hemmabyggd auth tillräckligt länge så landar all kritisk kontext på en eller två personer: vilken kund är konfigurerad hur, vilket fält du inte får röra, varför en tidigare migrering gjordes på ett visst sätt. Sällan dokumenterat. Det finns i någons huvud.

När hen är där, går leveransen. När hen inte är, tvärstannar enterprise-pipelinen, och din viktigaste infrastruktur har ingen ägare, bara "den som vet".

Vissa team går längre och bygger plattformar där kunderna själva kan konfigurera SSO. Låter moget – tills du frågar hur många kunder som använder det. Vi såg ett team med 1,5 miljoner aktiva i månaden som höll liv i ett sånt system för kanske ett dussin kunder.

Du trodde du byggde en funktion. Du byggde en intern produkt, med kostnaden utsmetad på ett fåtal kunder. Är identitet din affärsidé är det värt det. Annars är det den dolda fakturan i dess renaste form.

Var vill du ha dina ingenjörer?#

Tillbaka till tjugoåriga SaaS:et. Det är inga svaga ingenjörer. Att hålla ett branschsystem levande i decennier visar att man kan sina kunder.

Det är hela poängen. Rakt på sak: vill du ha dem handunderhållande varje kunds SSO och riva ut tjugo års behörighetslogik ur hundratals moduler – eller vill du ha dem jobba djupare med branschsystemet?

Det handlar inte om perfektionism. Det är resursprioritering. Om du bygger bill-betalningar, vertikal SaaS, medlemsportal eller operationssystem, är det ingen kund som betalar ett öre extra för att du byggde ditt eget OAuth-server.

Ett bill-pay-team vi intervjuade sade det rakt: deras egen IdP funkade, men det är en strategifråga. Skriv inte mycket kod för auth. Spara energin till att göra bill pay så bra som möjligt, och använd det mest beprövade auth-systemet för resten.

Auth måste vara tillförlitligt. Men "tillförlitligt" är inte lika med "byggt av dig". Din databas, e-post och molntjänster måste också vara robusta, och ett moget team antar inte att allt måste vara eget bara för att det är viktigt.

För de flesta produkter är auth en kärndependency, inte en differentierare. Om inte identitet är din affär, är en identitetsprodukt internt oftast inget konkurrensmedel. Det är en resursläcka på sikt.

När är det ändå okej att bygga eget auth?#

Det är lätt att gå till överdrift: skriv aldrig auth-kod. Det är fel det med.

I vissa skeden är det helt rimligt att bygga själv (eller halvvägs): interna demos, tidiga prototyper, valideringsprojekt. Och om du har extremt specifik, finmaskig auktorisering som verkligen inte går uttrycka i någon färdig lösning, behåll den delen internt, men låt en extern plattform hantera autentisering, sessioner, SSO, MFA och användarkatalog.

Se bara upp för POC-sluttningen. Vi har sett mönstret: två utvecklare lägger sex–åtta månader på prototyp mot extern lösning. Ansatsen är inte dålig. Deras dom är: det blir bra. Men det var aldrig tänkt att bära skalning.

Och ett proof-of-concept är det lättaste att råka bygga in till långsiktig arkitektur. Sex månader senare är det "nuvarande lösning", två år senare "det gamla systemet", fem år senare "infrastruktur vi inte kan röra". Bästa tiden att lämna hemmabyggd auth är oftast innan det blir grunden.

Så gränsen är denna: frågan är inte om du skrivit autenticieringskod. Det är om du tagit över generisk identitetsinfrastruktur och behållit den internt långsiktigt.

Bygg unika förmågor själv. Var försiktig med kärnidentiteten. Och bygg dig inte av misstag en hel CIAM-plattform.

Om du inte bygger den, hur väljer du auth-lösning?#

Om du väljer att inte bygga, kommer nästa fråga: vems ska du köpa, och hur väljer du?

De flesta mogna lösningar täcker redan funktionerna: SSO, MFA, flera organisationer, enad inloggning, agentåtkomst. Så skillnaden är sällan feature-listan.

Det som är värt att jämföra (och lätt att missa) är punkterna nedan. De är aspekter av en sak: undvik att klättra upp ur din tusenrading kod för att bli inlåst i ett annat system du inte kan lämna.

• Håll dig till standardprotokoll, inte en leverantörs egen stack. OIDC, OAuth och RS256-signade JWT är redan välkända. Du läser claims ur en vanlig token, utan någon vendorspecifik API.
• Behåll en utgång. Om lösningen är öppen källkod och kan self-hostas, kan du lämna när du vill. (Men tänk på att långvarig drift själv är en egen dold kostnad.)
• Låt inte prissättning följa användartabellen. Avgift per registrerade eller aktiva användare skalar dåligt när tabellen bara växer, full med inaktiva, och blir en "tillväxtskatt". Det är den modellen som fick medlemsorg:en ovan att bygga eget.
• Din data ska inte vara inlåst. Du kan exportera användardata när du vill. Och att låta en nischad leverantör hålla känsliga data skyddar dig från risken att sitta på en dataskatt du aldrig borde förvalta.

Full transparens: Logto är auth-produkten vi byggde just utifrån dessa fyra punkter. Den är öppen källkod, self-hostbar och finns också som managed Cloud: använd Cloud för noll underhåll, eller self-hosta för full kontroll – och den dag du vill flytta vidare, är utgången öppen.

Inloggning, MFA, SSO och RBAC funkar direkt med OIDC, och debiteringen följer tokens, så du betalar för faktisk användning.

Det finns andra mogna produkter, och auth är inget med ett givet rätt svar. Om du utvärderar har jag skrivit en hel text om hur du väljer auth-lösning att använda.

Slutsats: förväxla inte långsiktig identitetsplattform med en vanlig funktion#

Att bygga eget auth är ofta rimligt dag ett. Fällan är att det växer till infrastruktur senare.

Varje företagskliv synliggör det på nytt: företagskunder vill ha SSO, säkerhetsavdelningen vill ha MFA, produkten vill ha enad inloggning, flera produkter måste kopplas ihop, AI-agenter vill åt resurser för användare. Bakom varje till synes liten funktion ligger en lång policykedja, och på längre sikt äter det av utvecklartid från din kärnprodukt.

Denna faktura landar inte dag ett. Oftast ser du den först efter flera år. Då märker du: den inloggningssida du skrev från början var redan identitetsinfrastruktur som skulle leva kvar hela produktens liv.

Auth är troligen inte din affärsidé. Ju snabbare du inser det, desto fortare kan du satsa resurser på det du verkligen bygger.

FAQ#

Ska man aldrig bygga eget autentiseringssystem?#

Nej. Tidiga demos, interna verktyg, valideringsprojekt eller mycket specifik finmaskig auktorisering som inte uttrycks av färdiga lösningar kan vara okej. Undvik att ta in långsiktig, generell identitetsinfrastruktur utan att veta det och lägga det på ett affärsteams underhållsansvar.

Vad är skillnaden på autentisering och auktorisering?#

Autentisering svarar på "vem är du". Auktorisering svarar på "vad får du göra". I verkliga SaaS är de ofta svåra att skilja: användare, organisationer, roller, behörigheter, sessioner, tokens, audit logs – allt hänger ihop. Så när du byter auth-system handlar det om mer än inloggningssidan.

Varför gör SSO för företag hemmabyggd auth komplext?#

Därför att du ska koppla din produkt till kundens identitetssystem. Olika kunder har olika IdPs, protokoll, claims, certifikat och organisationsmappningar. Att få igång första kunden betyder inte att resten är copy-paste. Ofta blir det handpåläggning som bara en person förstår.

Vi har kört eget i åratal. Kan vi ändå migrera?#

Ja, men en stor omläggning på en gång är sällan rätt sätt. Migrera lager på lager: lägg nya registreringar, inloggningar och enterprise-SSO på identitetsplattformen först, och flytta befintliga användare vid nästa inloggning. Ha återställningsväg och audit logs hela tiden, så att migreringen aldrig blir oåterkallelig.