Du kan bygga din egen auth på en dag. Det är fällan.
Dussintals B2B-team berättade samma historia för oss. Det börjar som en enkel inloggningssida. Sedan börjar riktig trafik passera, och plötsligt blir det identitetsinfrastruktur: grunden som hela din produkt vilar på.
Det såg ut som en funktion. Det lämnade efter sig en hel identitetsmodell.
Alla egenbyggda auth-lösningar börjar med några få rader kod. Problemen börjar efter lansering, när varje litet beslut tyst förstelnar till den modell hela din produkt antar är sann.
Dag ett: fyrtio rader kod
E-post, lösenord, hasha det, lagra det, jämför vid inloggning. Rent och klart.
Dag tvåhundra: en tyst identitetsmodell
Vem räknas som användare. Vilken organisation de tillhör. Vilken session som fortfarande är tillförlitlig. Hur åtkomst tas bort.
År fem: en grund du inte kan röra
Att byta ut inloggningssidan på papper betydde att bygga om identitetsgrunden i kod.
Hemmasnickrad auth fungerar fint – tills företaget utvecklas
Den loggar in folk i flera år utan incidenter. Sedan gör en affärsförändring att “tillräckligt” plötsligt blir “i vägen” över en natt. Dessa tre kommer nästan alltid för varje produkt som växer.
Enterprise-kunder börjar fråga efter SSO
Den första stora affären landar och inköp vill ha SSO via sitt eget Entra eller Google Workspace. Sedan både SAML och OIDC, eftersom nästa kund använder något annat. Varje kunds identitetslösning är olika, och nästan inget arbete kan återanvändas.
- Olika protokoll, fältmappningar och certifikatsbyten för varje kund
- SSO byggs inte en gång. Du bygger om det för varje företag du skriver kontrakt med
- Det blir snabbt handarbete som bara en ingenjör förstår från början till slut
Identitet som började utspridd måste nu bli enhetlig
Uppdelat per organisation, per produkt, ofta ärvt via förvärv. ”Enhetlig identitet” låter som en funktion; i kod betyder det att omdefiniera vad som räknas som en användare och en organisation.
- Kan en e-postadress tillhöra flera organisationer? Hur migrerar du gamla användarnamn?
- Nio produkter från förvärv betyder nio auth-stackar som körs parallellt
- Avsluta en avgång på alla samtidigt och granska allt på ett ställe
AI-agenter och CLI-er börjar agera för användares räkning
Det är inte längre bara personer i en webbläsare. Agenter, MCP-servrar och kommandorader påstår sig alla agera för en användare. Och din auth vet bara hur man loggar in en person på en sida.
- Vem utfärdas token till, med vilket scope och vilken audience?
- Bevilja bara ett verktyg eller en datadel, och dra sedan tillbaka det
- MCP och CLI-access bygger på OAuth, inte på ett inloggningsformulär
Den verkliga kostnaden är inte att bygga. Det är att bära det i åratal.
Den första versionen är billig: några ingenjörer, några veckor, klart. Sedan matar du det varje år med ingenjörstid som egentligen låg till ditt kärnsystem.
Fakturan ändrades – men inte kostnaden
Du får aldrig en faktura som säger ”autentisering.”
Det vilar tyst på en eller två personer
Den kritiska kunskapen finns i någons huvud, inte i dokumentationen.
Var vill du ha dina ingenjörer?
Ingen kund betalar dig mer för att du skrev din egen OAuth-server.
Om du inte bygger det, hur väljer du?
De flesta mogna auth-lösningar täcker redan funktionerna: SSO, MFA, organisationer, enhetlig inloggning, agent-tillgång. Den verkliga skillnaden är om du kan lämna. Klättra inte ur din egen kodradda bara för att fastna i någon annans system.
Standardprotokoll, inte en specialstack
En dörr du faktiskt kan gå igenom
Fakturering som inte följer din användartabell
Dina data låses aldrig in
Auth är troligen inte din kärnverksamhet. Behandla det som det.
Logto är open source, självhyst och finns också som en hanterad molntjänst. Inloggning, MFA, SSO och RBAC fungerar direkt med standard OIDC. Faktureringen följer tokens, och den dag du vill lämna står dörren öppen.