Den bedste selvhostede CIAM til B2B-SaaS-byggere

Hvis du har kigget på priserne hos nogle af SaaS-CIAM-platformene, har du sikkert bemærket, hvor dyre de bliver, og du har formentlig overvejet en selvhostet løsning.

Denne artikel handler om de fire selvhostede CIAM-platforme, som et lille B2B-SaaS-team reelt kan drive, uden at det bliver et fuldtidsjob nummer to: ZITADEL, FusionAuth, Logto og Ory Hydra. De har ikke alle samme form, og hvilken der er den rigtige for dig afhænger mindre af en funktionsliste og mere af, hvilken slags B2B-produkt du bygger. Jeg kørte dem side om side på én VPS i en uge for at lave denne sammenligning, og det følgende er den version, jeg ville sende til en stifter, der skriver til mig om CIAM.

Én ting fra start: det her handler om CIAM som produktfunktion, ikke om internt SSO til dit eget team.

Den korte version

Fire selvhostede CIAM-platforme, én linje til hver:

• ZITADEL hvis du vil have multi-tenancy og B2B-organisationer ud af boksen.
• FusionAuth hvis du vil have en poleret admin-brugerflade og en lang, forudsigelig udgivelseshistorik.
• Logto hvis du vil have den reneste udvikleroplevelse på dag ét.
• Ory Hydra hvis du bygger på protokolniveau og vil have OAuth 2.0-motoren, ikke en færdigtænkt login-app.

Kort sagt: ZITADEL er det sikreste første valg til et typisk B2B-SaaS, og resten af artiklen folder den begrundelse ud.

Hvorfor CIAM er en anden beslutning end internt SSO

Hvis SSO til dit interne team går ned, er skaden som regel begrænset. Dine ingeniører mister måske adgangen til Grafana eller et andet internt værktøj i en time. Går CIAM ned, kan dine betalende kunder slet ikke logge ind i produktet. Det flytter spørgsmålet fra "hvilket auth-værktøj er bekvemt for vores team?" til "hvilket auth-system kan vi stole på som en del af selve produktet?"

CIAM, altså den slags identitetsinfrastruktur et B2B-SaaS har brug for, kræver også primitiver, som mange interne SSO-værktøjer ikke fremhæver. Din kunde er ikke én bruger; det er en organisation (en tenant) med egne brugere, roller, branding og muligvis sin egen SAML-forbindelse til en virksomheds-IdP. Du autentificerer ikke bare mennesker; du isolerer én virksomheds brugere fra en andens inde i det samme produkt. Det er den B2B-form, de fire værktøjer nedenfor rammer, hver på sin måde. Keycloak har nu fuldgyldige Organizations, så at afvise det som noget kun til medarbejdere ville være forældet; jeg forklarer fravalget i FAQ'en.

Trekanten bygge, købe eller selvhoste ser også anderledes ud her. At skrive OAuth fra bunden er en unødvendig fejl. Du leverer et SaaS-produkt, ikke en identitetsudbyder. At købe managed (Auth0, Clerk, WorkOS) er det rigtige valg, når dit team har nul ops-kapacitet og et fornuftigt budget. Jeg ville aldrig råde en to-mands startup til at selvhoste auth på dag ét. Selvhosting bliver rationelt, når managed CIAM's pris per MAU overstiger omkostningen til infrastruktur plus løbende ingeniørtid, eller når du har brug for direkte kontrol over udrulningen og dataplanet. I de teams, jeg har arbejdet med, rammer det punkt typisk et sted mellem "vi har et rigtigt produkt" og "vi har en rigtig customer success-funktion".

Hvis du leder efter SSO til dine egne apps snarere end dine kunders, er det en anden sammenligning end denne. Videre til vores topvalg.

De fire værktøjer, ét ad gangen

Jeg valgte de fire, fordi de er CIAM-formede nok til at kunne vurderes som produktinfrastruktur og ikke bare som internt SSO. ZITADEL, FusionAuth, Logto og Ory giver alle en reel selvhostet vej og nok momentum til at blive taget alvorligt. De rene biblioteker, workforce-SSO-løsningerne og de mindre modne muligheder hører bedre hjemme i FAQ'en.

ZITADEL

ZITADEL er en schweizisk udviklet identitetsplatform skrevet i Go, med en event-sourced arkitektur og PostgreSQL som backend. Per 27. juli 2026 er den nyeste GitHub-udgivelse the 4.16 series, current as of July 2026. ZITADEL skiftede fra Apache 2.0 til AGPL-3.0 fra v3; ved normal SaaS-brug er den praktiske konsekvens som regel mindre skræmmende, end det lyder, og jeg gennemgår detaljerne i FAQ'en.

Det, der adskiller ZITADEL for B2B-SaaS: organisationer og multi-tenancy er fuldgyldige primitiver, ikke funktioner du selv stykker sammen af generiske objekter. Du opretter en Organization, den får sine egne brugere, politikker, branding og adgangsindstillinger, og du kan tildele den projekter, så dens administratorer selv styrer rolletildeling for deres egne brugere. Du behøver ikke opfinde begrebet "tenant" oven på generiske brugere. Du starter med det.

Udvikleroplevelsen er API-first, med de nuværende v2 REST-ressource-API'er plus gRPC- og REST-adgang til de gamle v1-tjenester. Officielle SDK'er og community-SDK'er dækker de gængse serverstakke. Admin-konsollen er funktionel, men mere enkel end FusionAuths.

Min vurdering: Bygger du et B2B-SaaS og ved, at du får tenants, ville jeg starte med ZITADEL. Blandt de selvhostede muligheder er det den, der tydeligst er formet omkring B2B-login-problemet.

FusionAuth

FusionAuth er en amerikansk platform fra Inversoft, LLC (et Delaware-LLC, der handler under navnet FusionAuth), som har været her længere end de tre andre, og det kan mærkes, på den gode måde. Admin-brugerfladen føles markant mere gennemdesignet end de øvriges, dokumentationen er moden, og udgivelsestakten er stabil frem for hæsblæsende. Hvis du nogensinde har arvet en fire år gammel auth-integration og stille takket den forrige udvikler for at vælge den kedelige løsning, så er FusionAuth den udgave af CIAM, der fortjener den tak.

Licensen er dét, folk snubler over: FusionAuth Community er gratis at selvhoste, men kerneproduktet er ikke open source. Produktet er underlagt FusionAuths egen licens, og grænserne betyder noget, hvis du planlægger at videredistribuere, indlejre, ombrande, videresælge eller hoste FusionAuth for dine egne kunder. Den selvhostede Community-udgave dækker kernescenariet for B2B-SaaS; betalte planer tilføjer funktioner såsom IdP-initieret SAML, avanceret MFA og applikationsspecifikke temaer, mens SCIM, Tenant Manager og MFA-politikker på applikationsniveau ligger i Enterprise.

Om B2B-formen: FusionAuth modellerer tenants og applikationer, men abstraktionen er "containeriseret auth per tenant" snarere end "B2B-organisationer som domæneobjekt". Det virker (jeg har leveret produkter på det), men multi-tenancy føles mere som et isolationsprimitiv end som en fuldgyldig B2B-model. De officielle SDK'er og klientbiblioteker er brede:

• Angular
• React
• Vue
• iOS
• Android
• Go
• Java
• .NET
• PHP
• Python
• Ruby
• TypeScript

Serverbibliotekerne er tynde API-klienter. Admin-konsollen er sammenlignet med de andre nemmere at give videre til en ops-medarbejder uden udviklerbaggrund.

Min vurdering: Hvis dit team værdsætter poleret brugerflade og en lang, forudsigelig historik højere end B2B-native primitiver, så FusionAuth. Det er det mest "kedelige" valg her, og det er en kompliment.

Logto

Logto er den nyeste af de fire, udviklet af Silverhand Inc. og licenseret under MPL-2.0, og det er den, der mest tydeligt går op i sit dashboard. Opsætningen på dag ét går forholdsvis hurtigt. Du provisionerer, klikker dig gennem guiden og har en fungerende OIDC-udbyder med et anstændigt standard-login-UI på cirka femten minutter (jeg tog tid på det i den uge, hvor jeg kørte alle fire side om side). De officielle quickstarts dækker moderne frameworks og serverstakke, så hvis din stak er "Next.js + Postgres + et eller andet", vil du føle dig hjemme.

Dets B2B-svar hedder Logto Organizations. Det dækker de centrale B2B-primitiver: organisationsmedlemskab, roller med organisationsomfang, medlemsinvitationer, just-in-time provisionering og enterprise-SSO-integration. Organisationsmodellen er yngre end ZITADELs, så jeg ville teste ethvert usædvanligt SAML-, SCIM- eller federationsflow mod dine målkunder, før du binder dig.

Afvejningen er modenhed: Logto er den nyeste mulighed her. Roadmappen bevæger sig hurtigt, hvilket er skønt, når en funktion du har brug for lander, og ubehageligt, når en breaking change gør. Ligger dit B2B-SaaS i den enklere ende af multi-tenancy-spektret (få organisationer og ingen eksotiske federationskrav), gør Logtos udvikleroplevelse resten af beslutningen lettere.

Min vurdering: Vil du have den hurtigste første dag, og er dine B2B-behov stadig relativt enkle, så Logto.

Ory Hydra (og Ory-stakken)

Ory Hydra er OAuth 2.0 / OpenID Connect-serveren fra Ory-økosystemet, licenseret under Apache-2.0. Den fulde Ory-stak parrer Hydra med Ory Kratos (identitet og brugeradministration, selvbetjent login, registrering, MFA og kontogendannelse), Ory Keto (en autorisationsserver i Zanzibar-stil, der fungerer som policy decision point) og Ory Oathkeeper (en identitets- og adgangsproxy, der autentificerer, autoriserer og ændrer indgående HTTP-forespørgsler). Du samler det, du har brug for. Alt er skrevet i Go, og API'erne er rene.

Hagen (og det er ikke en fejl; for det rette team er det en fordel) er, at Hydra er motoren, ikke applikationen. Efter design forbinder Hydra til en separat login- og samtykke-app , som du selv leverer. Vil du have en færdig login-skærm, er dette ikke værktøjet. Bygger du noget, hvor auth-flowet er en del af dit produkt (en udviklerplatform, en skræddersyet B2B-portal eller et API-first-produkt med eget onboarding), er fraværet af en påtvunget UI præcis det, du vil have.

B2B-historien er sammensættelig frem for nøglefærdig. Du kan modellere multi-tenancy ved at koble Kratos-skemaer og Keto-relationer til dit eget organisationslag, og det virker, men det er dig, der trækker ledningerne. Prisen er mere blikkenslagerarbejde; gevinsten er kontrol over oplevelsen. Orys dokumentation dækker protokolfladen i dybden, men den sammensættelige model forudsætter, at du er tryg ved selv at træffe beslutninger på protokolniveau. Siger "audience claim" eller "PKCE" dig ingenting, så start med en af de tre andre.

Min vurdering: Bygger du noget på protokolniveau (auth-gateway, brugerdefinerede flows, udviklerplatform), og føles standardapplikationerne begrænsende, så er Ory det rigtige svar. For et typisk B2B-SaaS, der vil have login til at virke i dag, er det ikke.

Sammenligningen på et øjeblik

Her er opsummeringen af de fire værktøjer i én tabel, nyttig ved anden gennemgang, ikke en erstatning for profilerne ovenfor.

Hvilken bør du starte med?

Fire korte scenarier, der dækker de fleste teams, jeg ville tale med om det her.

Du bygger et B2B-SaaS og ved, at du får tenants. Start med ZITADEL. Primitiverne til multi-tenancy og organisationer er lavet præcis til dette, API-fladen er omfattende, og du bruger mindre tid på at opfinde tenant-modellen end med nogen af de tre andre. Skiftet til AGPL fortjener et licenstjek, men en umodificeret, separat integreret udrulning er som regel et ligetil SaaS-scenarie.

Du vil have den polerede admin-brugerflade og en stabil, forudsigelig platform. FusionAuth. Community-planen dækker mange teams kernebehov; afsæt tid til at læse licensen og funktionsmatricen grundigt. Funktioner som IdP-initieret SAML, avanceret MFA og applikationsspecifikke temaer kræver en betalt plan, mens SCIM, Tenant Manager og MFA-politikker på applikationsniveau ligger i Enterprise.

Dine B2B-behov er enkle i dag, og du vil have den hurtigste første dag. Logto. Dets udvikleroplevelse på dag ét var den hurtigste i min sammenlignende test. Accepter, at du satser på et yngre økosystem, og genovervej valget, hvis dine krav vokser til federationsspecialtilfælde, du ikke har testet.

Du bygger noget, hvor auth-flows er en del af produktoplevelsen. Ory Hydra (plus Kratos, plus Keto hvis du har brug for rettigheder). Du kommer til at skrive mere kode. Du får mere kontrol. Er den byttehandel ikke indlysende for dig, er du ikke Orys målgruppe. Vælg en af de tre andre.

Passer to af disse beskrivelser på dig, så vælg ZITADEL som standard. Det passer bredest, og det er den, jeg ville give et lille stifterteam uden mange opfølgende spørgsmål.

Hvad selvhosting koster dig (driftsmæssigt)

Her kommer den uromantiske del af artiklen.

Din PostgreSQL-backupdisciplin er nu noget, din forretning afhænger af. På tværs af disse udrulninger kan den identitetstilstand, du skal beskytte, omfatte brugerposter, hashede loginoplysninger, MFA-hemmeligheder, OAuth-klientlegitimation og sessionsdata. Mister du den tilstand, kan dine kunder miste muligheden for at logge ind. Sæt automatiske backups op, før din første rigtige bruger tilmelder sig, test gendannelsen, og læg backuppens sundhed i samme alarmkanal som din applikations oppetid.

Udgivelsestempoet ændrer sig over tid. ZITADEL v4.16.1 udkom 17. juli 2026 efter flere juni-udgivelser, mens hvert projekt her holder sin egen kadence og kompatibilitetspolitik. Behandl den kadence som et vedligeholdelsesspørgsmål, ikke som en genvej til at bedømme kvalitet. Læs release notes, før du kører docker compose pull, og planlæg et tilbagevendende patch-vindue. At springe opdateringer af identitetsudbyderen over i måneder kan efterlade dig bagud på sikkerheds- og kompatibilitetsrettelser ved dit første rigtige review.

De trivielle ting, der altid lister sig ind på én: fornyelse af TLS-certifikater (brug en reverse proxy med Let's Encrypt, automatisér fornyelser og alarmér ved fejl), konfiguration af udgående mail til verificerings- og nulstillingsmails (SES, SendGrid, Postmark: vælg én og konfigurér SPF/DKIM/DMARC ordentligt, ellers lander dine nulstillingsmails i spam), rotation af OAuth-klientlegitimation når en udvikler siger op, og rate limiting på login-endpoints, så et credential stuffing-angreb ikke låser din CPU.

Pro-tip: bruger du managed Postgres, så gå ikke ud fra, at runtime-databasebrugeren også kan oprette skemaet. Opret databasen og brugeren på forhånd, tildel de nødvendige ejerskabs- eller opsætningsrettigheder, og kør den første opsætning med de legitimationsoplysninger, hvert værktøj forventer. Ellers kan din første kørsel fejle med en uklar databaserettighedsfejl, og du brænder en time af på det forkerte spor.

Det, den selvhostede vej sparer dig i kroner, koster den dig i ejerskab. Efter opsætningen bør du afsætte nogle få ingeniørtimer om måneden til at holde identitetslaget sundt. Teams, der afsætter nul tid, opdager som regel omkostningen senere: under et nedbrud, ved et mærkeligt SAML-specialtilfælde eller ved deres første sikkerhedsgennemgang.

Hvor du udruller dem

En Linux-VPS med Docker Compose kan være et fornuftigt udgangspunkt til evaluering og beskedne arbejdsbelastninger, men produktionsdimensionering og høj tilgængelighed afhænger af trafik, sikkerhedskrav og din tolerance for nedetid. Sådan placerer de gængse udrulningsmuligheder sig:

• Delt hosting kan ikke køre nogen af dem. De kræver persistent lagring, brugerdefinerede porte, root-adgang til container-runtime og en rigtig databasebackend. PostgreSQL er standardvejen for de fleste på denne liste, men det er bogstaveligt talt ikke den eneste understøttede database for hvert værktøj.
• Kubernetes kan køre alle fire, men den officielle vej er ujævn. ZITADEL, FusionAuth, og Ory udgiver egne Helm-charts, mens Logtos dokumentation om selvhosting fokuserer på Docker- og VM-udrulning. For et lille B2B-SaaS, der ikke er nået til det punkt, hvor Kubernetes betaler sig andre steder, er det som regel overengineering. Grib til det, når resten af din infrastruktur allerede er der.
• Bare metal er fint, hvis du allerede kører på det. Det gør de fleste B2B-SaaS-teams ikke.

Til en lille single-node pilot ville jeg starte på 4 GB RAM, 2 vCPU og 60 GB NVMe-lagring og derefter belastningsteste det rigtige login-flow. Det er et planlægningsudgangspunkt, ikke et universelt produktionsminimum. Applikationerne er forholdsvis lette, men PostgreSQL kræver hukommelse, og password-hashing kræver CPU-luft. ZITADELs produktionsvejledning anbefaler at have fire CPU-kerner til rådighed til spidsbelastning ved password-hashing.

Når produktet er reelt, og trafikken er vedvarende, skalerer du efter målinger. Hurtig lagring hjælper PostgreSQL-latens, mens CPU-luft betyder noget under samtidig password-hashing. Hold øje med hukommelse, database-I/O, login-latens og CPU-mætning i stedet for at antage, at én ressource betyder mest.

At køre CIAM i produktion betyder, at oppetiden nu er dit problem. Vi kører Cloudzy Linux VPS instanser til denne type arbejdsbelastning, med NVMe-lagring og en oppetids-SLA på 99,95 % på den underliggende platform. Cloudzy tilbyder desuden en ZITADEL-VPS med ét klik hvis du hellere vil springe det indledende provisioneringsscript over; de tre andre leverer officielle container-images til en Docker-baseret opsætning. Vil du have et ledelsesniveau-blik på, hvordan adgangskontrol passer ind i resten af din sikkerhedsposition, dækker guiden til IAM-best practices emnet fra politiksiden.

Ofte stillede spørgsmål

Påvirker ZITADELs AGPL-licens mit SaaS?

Som regel ikke ved en umodificeret, separat integreret udrulning, men dette er ikke juridisk rådgivning. ZITADELs AGPL-forpligtelser gælder ZITADEL selv. Hvis du ændrer ZITADEL og driver den ændrede version som en netværkstjeneste, kan licensen kræve, at du stiller den tilsvarende kildekode til rådighed under AGPL. ZITADELs offentliggjorte holdning er, at det at bruge en umodificeret instans som identitetstjeneste for dit SaaS ikke i sig selv kræver, at du licenserer din separate applikation under AGPL. Læs ZITADELs licensmeddelelse og søg juridisk rådgivning, hvis du ændrer, videredistribuerer, indlejrer eller tilbyder softwaren til tredjeparter. Der findes også en kommerciel licens.

Hvorfor er Keycloak eller Authentik ikke på denne liste?

Keycloak og Authentik er fremragende selvhostede identitetsværktøjer (jeg bruger dem), men at udelukke Keycloak, fordi det mangler B2B-organisationer, ville nu være forkert: nuværende Keycloak-udgivelser indeholder Organizations, organisationsgrupper og delegeret administration. Jeg lod det være ude, fordi denne sammenligning fokuserer på fire muligheder med en mere direkte vej for et lille B2B-SaaS-team; Keycloak fortjener sin egen vurdering, når JVM-drift, økosystemets dybde og fleksibilitet på realm-niveau betyder noget. Authentik passer stadig bedre til workforce- og intern-app-SSO end til produktnativ tenant-modellering.

Er selvhosting billigere end Auth0?

Ved lave MAU-tal ofte ikke. Dine ingeniørtimer koster mere end Auth0-regningen på det tidlige startup-niveau. Selvhosting vinder økonomisk på den skala, hvor managed CIAM's pris per MAU overstiger den samlede omkostning til en lille VPS plus de få ingeniørtimer om måneden, du bruger på det. Det præcise break-even afhænger af dit teams timepris, din MAU-vækstkurve, og om dit produkt kræver enterprise-funktioner, der skubber dig op i Auth0's dyrere niveauer. Betragt besparelsen som reel, men ikke øjeblikkelig.

Hvad er den mindste VPS-størrelse til et CIAM i produktion?

Til en lille single-node pilot er 4 GB RAM, 2 vCPU og NVMe-lagring et fornuftigt udgangspunkt, ikke en produktionsgaranti. Dimensionér ud fra din databases størrelse, samtidig login-belastning, omkostningen ved password-hashing og dit oppetidsmål. ZITADELs egen produktionsvejledning anbefaler fire tilgængelige CPU-kerner til hashing-spidser; andre værktøjer og trafikmønstre kræver deres egne belastningstest.

Kan jeg senere migrere fra et managed CIAM til selvhostet?

Ja, men planlæg det som et rigtigt projekt. Nulstilling af adgangskoder er ikke uundgåelig: eksporterbarhed og understøttede hash-formater varierer, og nogle mål understøtter bulk- eller just-in-time-brugermigrering , mens andre kræver en nulstilling. MFA-faktorer, OAuth-klienter, aktive sessioner, e-mailverifikationsstatus og tenant- eller rollemapninger kræver særskilt behandling. Hvis du allerede har en mistanke om, at du senere selvhoster, så noter de eksport- og migreringsbegrænsninger, inden du vælger den managed udbyder.