Du har otte Docker-containere kørende på en VPS. Gitea, Nextcloud, Grafana, Vaultwarden, n8n, Portainer, en statusside og én intern app, du selv har skrevet. Hver af dem har sit eget login. Du kopierer adgangskoder fra din adgangskodehåndtering hver morgen, og du er begyndt at spekulere på, om single sign-on er de driftsmæssige omkostninger værd.
Det er det som regel. Spørgsmålet er, hvilken identitetsudbyder du skal køre.
Keycloak er det velkendte standardvalg, men det bedste match afhænger af, hvordan din stak ser ud, hvor mange brugere du administrerer, og om du integrerer software, du allerede kører, eller bygger autentificering ind i dine egne applikationer.
Denne sammenligning af selvhostet SSO ser på Authentik, ZITADEL, Keycloak og Authelia gennem de beslutninger, der betyder noget, når først de er udrullet: protokolunderstøttelse, brugerstyring, udviklerworkflow, ressourcekrav, og hvad der sker, når din identitetsudbyder går ned.
Hvorfor selvhostet SSO betyder noget
Når flere applikationer afhænger af de samme personer og grupper, holder separate logins op med at være praktiske. En selvhostet identitetsudbyder giver dig ét sted at administrere konti, MFA, gruppemedlemskab og adgangspolitikker i stedet for at konfigurere de kontroller separat i hver applikation.
Bagsiden er lige så vigtig: IdP'en bliver infrastruktur, som andre applikationer afhænger af. Nye logins og tokenfornyelser kan fejle, når den er utilgængelig, så backups, nødadgang, opgraderinger og oppetid betyder mere her end for en almindelig selvhostet app.
TL;DR
Vælg Authentik, hvis du vil have det bedste standardvalg
Til et homelab, en stak af interne værktøjer eller et lille team, der forbinder eksisterende applikationer via OIDC eller SAML, er Authentik det stærkeste standardvalg. Dets admin-workflow er lettere at gå til end Keycloaks, det understøtter flere integrationsmetoder, og dets officielle Docker Compose-opsætning starter ved 2 CPU-kerner og 2 GB RAM.
Vælg ZITADEL, hvis du bygger apps
Vælg ZITADEL, når autentificering er en del af det produkt, du bygger. Dets organisationsmodel, API'er, multi-tenancy, OIDC, SAML, passkeys, MFA og understøttelse af LDAP-identitetsudbydere giver mere mening for SaaS- og B2B-applikationsteams end for et typisk homelab.
Vælg Keycloak, hvis du har brug for enterprise-identitetsfunktioner
Vælg Keycloak, når du har brug for dybere LDAP- eller Active Directory-føderation, flere realms, finkornede autorisationspolitikker eller et miljø, der allerede er bygget op omkring Keycloak. Dokumentationen anbefaler en hukommelsesgrænse på 2 GB til mindre produktionsklare Keycloak-containere; en alt-i-én-VPS, der også kører PostgreSQL, har brug for ekstra luft.
Alternativ: Vælg Authelia, hvis du primært har brug for en loginmur
Vælg Authelia, når dit hovedproblem er at beskytte applikationer i reverse proxy-laget frem for at køre en fuld identitetsplatform. Den kan også fungere som OpenID Connect-udbyder, men autentificering i reverse proxyen forbliver dens tyngdepunkt.
Hvad du skal tjekke, før du vælger et SSO-værktøj
Før du sammenligner funktioner, skal du holde hvert værktøj op mod de applikationer, protokoller og identitetskilder, du allerede skal understøtte.
Hvor mange apps har brug for SSO?
Start med applikationerne, ikke identitetsudbyderen. En stak med seks applikationer, der allerede understøtter OIDC eller SAML, er et andet problem end en stak af gamle interne værktøjer, der intet kender til nogen af protokollerne. Det første tilfælde peger mod en fuld IdP. Det andet kan have brug for autentificering i reverse proxy-laget.
Understøtter dine apps OIDC eller SAML?
OIDC er det almindelige valg til moderne webapplikationer. SAML betyder stadig noget i enterprise-software og ældre integrationer. LDAP kan betyde noget, når applikationen forventer et directory frem for et webbaseret SSO-flow. Tjek, hvad hver applikation faktisk accepterer, før du vælger den IdP, der skal sidde i midten.
Administrerer du brugere eller bygger du login ind i en app?
Hvis det meste af dit arbejde foregår i en admin-grænseflade, mens du forbinder eksisterende applikationer, er Authentik det naturlige udgangspunkt. Hvis autentificering er en del af et produkt, du bygger, og du forventer at oprette organisationer, brugere og rettigheder via kode, er ZITADEL meget tættere på det workflow.
Har du brug for LDAP, Active Directory eller avancerede politikker?
Authentik, ZITADEL og Keycloak kan alle i en eller anden form forbinde til LDAP-baserede identitetskilder, så LDAP alene afgør ikke længere sammenligningen. Keycloak bliver mere interessant, når directory-føderation kombineres med flere realms, detaljerede mappers, synkroniseringskrav eller autorisationspolitikker på ressourceniveau.
Authentik vs ZITADEL vs Keycloak vs Authelia
De fire værktøjer overlapper på SSO, men de nærmer sig identitet fra forskellige retninger: applikationsintegration, produktidentitet, enterprise-IAM og adgang via reverse proxy.
Authentik
Authentik kører sin kerneudrulning som en server, en worker og en PostgreSQL-database. Redis er ikke længere en del af stakken: Authentik fjernede afhængigheden helt i 2025.10-udgivelsen. Den aktuelle Docker Compose-dokumentation kræver en vært med mindst 2 CPU-kerner og 2 GB RAM.
Det definerende træk er admin-grænsefladen. Authentiks flow-motor, applikationsprovisionering og gruppebaserede politikker er lettere at gå til end Keycloaks bredere konfigurationsmodel. Hvis du nogensinde har sat en OIDC-applikation op i Keycloak og derefter brugt tid på at finde ud af, hvorfor dine token-claims manglede, bemærker du hurtigt forskellen.
Den understøtter SAML, OAuth2/OIDC, LDAP og RADIUS. Den er det rigtige standardvalg til et homelab eller et lille engineering-team, der kører en stak af selvhostede apps.
ZITADEL
ZITADEL er primært skrevet i Go, licenseret under AGPL-3.0 og ligger på v4.x-udgivelseslinjen. Udrulningen består af et Go-API, en Next.js-loginbrugerflade og PostgreSQL, og de aktuelle krav understøtter PostgreSQL 14 til 18. Den officielle Docker Compose-dokumentation kræver en vært med mindst 2 GB RAM.
Det definerende træk er API'et. ZITADEL eksponerer en komplet identitetsflade over gRPC og REST og er bygget på en multi-tenant-model fra starten. Hvis du bygger et SaaS-produkt og vil have, at loginlaget er programmerbart, automatiserbart og multi-tenant som standard, er ZITADEL tættere på det, du vil have, end alternativerne.
Den understøtter OIDC, SAML, passkeys, MFA, LDAP-identitetsudbydere og en SCIM v2-grænseflade, der i øjeblikket er markeret som Preview. Dens organisationsmodel og API-first-workflow gør den til et bedre match for produktteams end for et simpelt homelab.
Keycloak
Keycloak er en Java-baseret platform til identitets- og adgangsstyring, der kører på Quarkus. Den har en større konfigurationsflade end de andre muligheder her, især når Realms, Clients, Roles, brugerføderation og Authorization Services kommer i spil.
Dens officielle containerdokumentation anbefaler en hukommelsesgrænse på 2 GB til mindre produktionsklare udrulninger. Det tal dækker selve Keycloak-containeren; hvis PostgreSQL deler den samme VPS, skal værten have mere luft.
Grunden til at acceptere den kompleksitet er konkret. Keycloak kan føderere LDAP- og Active Directory-directories, logge bruger- og administratorhændelser og håndhæve finkornet autorisation med RBAC, ABAC, brugerbaserede, kontekstbaserede og andre politiktyper. Hvis du har brug for de kontroller, har den ekstra konfiguration et formål.
Authelia
Authelia er den mindste af de fire: Apache 2.0-licenseret, én enkelt Go-binær, i øjeblikket på v4.39.x. Arkitekturen er anderledes end de tre andres: Authelia sidder foran en reverse proxy (nginx, Traefik, Caddy, HAProxy) og afgør, om forespørgsler må nå backend.
Authelia indeholder også en OpenID Connect-udbyder. Dokumentationen beskriver stadig OIDC-implementeringen som åben beta, men udbyderen er OpenID-certificeret til profilerne Basic OP, Implicit OP, Hybrid OP, Form Post OP og Config OP. Dens OIDC-funktionssæt er smallere end det, Authentik eller Keycloak leverer til identitetsstyring, og det er derfor, Authelia stadig giver mest mening, når autentificering i reverse proxyen er hovedopgaven.
Vi vender tilbage til Authelia i et selvstændigt afsnit. Den korte version: Authelias tyngdepunkt er adgangskontrol i reverse proxyen, ikke fuld identitetsstyring.
Funktionssammenligning
Tabellen nedenfor begrænser sammenligningen til de forskelle, der påvirker udrulning og den daglige administration.
| Funktion | Authentik | ZITADEL | Keycloak | Authelia |
|---|---|---|---|---|
| Understøttede protokoller | OAuth2/OIDC, SAML, LDAP, RADIUS, proxy-autentificering | OAuth2/OIDC, SAML, LDAP-identitetsudbyder, SCIM v2 Preview | OAuth2/OIDC, SAML, LDAP- og Active Directory-føderation | OIDC-udbyder plus autentificering i reverse proxyen |
| Bruger- og gruppestyring | Brugere, grupper, politikker, flows, applikationsbindinger | Brugere, organisationer, projekter, roller, grants | Brugere, grupper, realms, klientroller, realm-roller, føderation | Letvægts brugerstyring, typisk baseret på filer eller LDAP |
| Udvikleroplevelse | API tilgængeligt, men admin-grænsefladen er den største styrke | API-first, stærk organisations- og multi-tenant-model | Modne REST-API'er med en større IAM-model at lære | Primært konfigurationsdrevet |
| Enterprise-funktioner | Politikker, føderation, outposts, adgangskontrol til applikationer | Organisationer, projekter, passkeys, føderation, SCIM v2 Preview | Dyb føderation, flere realms, hændelser, Authorization Services | Adgangskontrolregler og stærk reverse proxy-integration |
| Opsætningens sværhedsgrad | Lettere udgangspunkt for de fleste selvhostede applikationsstakke | Bedst når teamet tænker i API'er og produktidentitet | Flere begreber og mere konfiguration, men dybere kontrol | Enklest når opgaven primært er autentificering i reverse proxyen |
| Ressourcevejledning | Officielt Compose-minimum: 2 CPU-kerner og 2 GB RAM | Officielt Compose-minimum for værten: 2 GB RAM | Anbefalet containerhukommelse på 2 GB til mindre produktionsudrulninger | Intet direkte sammenligneligt officielt RAM-minimum |
Hvilket værktøj passer til hvilken stak?
Det bedste match ændrer sig med, hvem der driver IdP'en, og hvordan applikationerne integrerer med den.
Bedste valg til et homelab
Authentik er standardvalget til et homelab, hvor de fleste applikationer allerede understøtter OIDC eller SAML. Det giver dig en fuld identitetsudbyder uden at kræve, at du overtager Keycloaks bredere IAM-model. Hvis det meste af stakken har brug for en loginskærm i reverse proxyen frem for indbygget SSO, kan Authelia være det enklere valg.
Bedste valg til en lille virksomheds stak
Authentik passer til de fleste små interne applikationsstakke, især når målet er ét identitetslag til værktøjer som Grafana, Gitea, Nextcloud og Vaultwarden. Keycloak bliver mere attraktiv, når et eksisterende directory, flere realms eller dybere autorisationspolitikker er en del af kravet.
Bedste valg til udviklere og SaaS-produkter
ZITADEL er det stærkeste match, når autentificering er en del af det produkt, du bygger. Dens organisationsmodel, multi-tenancy, API'er og automatiseringsflade giver mere mening, når brugere og tenants skal oprettes fra applikationskode frem for primært gennem et admin-panel.
Bedste valg til enterprise- eller compliance-tunge teams
Keycloak giver mening, når kravlisten omfatter kompleks directory-føderation, flere realms, detaljerede autorisationspolitikker og et team, der kan drive den ekstra IAM-kompleksitet. At selvhoste Keycloak gør ikke i sig selv et miljø compliant; backups, tilgængelighed, logning, adgangsgennemgange og ændringskontrol hører stadig til hos dit team.
Bedste valg til apps uden indbygget SSO
Authelia er det klareste match, når autentificering skal ske, før forespørgsler når applikationen. Den fungerer særligt godt med reverse proxies, der beskytter ældre interne værktøjer, dashboards og tjenester, som ikke selv understøtter OIDC eller SAML.
Den svære del af at selvhoste SSO
Når SSO først er obligatorisk, kan en konfigurationsfejl eller en mislykket gendannelse ramme flere applikationer på én gang.
Installation og konfiguration
At få containerne til at køre er kun det første skridt. DNS, TLS, redirect-URI'er, token-claims, gruppemapninger, e-maillevering og nødadgang er der, hvor en SSO-udrulning begynder at blive infrastruktur frem for endnu en Docker-app.
Serverressourcer
IdP'en er kun en del af ressourcebudgettet. PostgreSQL, reverse proxies, workers, adgangskodehashing, logs og directory-synkronisering kan alle konkurrere om CPU og hukommelse, når de deler én VPS.
Database- og backupstyring
Authentik, ZITADEL og almindelige Keycloak-produktionsudrulninger afhænger af en database. Tag backup af den database uden for serveren, dokumentér, hvordan den gendannes, og test gendannelsen. Et vellykket backupjob er ikke det samme som en fungerende gendannelsesprocedure.
Risici ved udelukkelse og gendannelse
En forkert redirect-URI, en udløbet client secret, en afbrudt directory-forbindelse eller en for streng politik kan låse administratorer ude sammen med alle andre. Hav en gendannelsesvej, der ikke afhænger af det autentificeringsflow, du forsøger at reparere.
Hold IdP'en tilgængelig
Et IdP-nedbrud afslutter ikke nødvendigvis alle eksisterende applikationssessioner med det samme. Eksisterende sessioner kan fortsætte, indtil deres egne tokens eller cookies udløber, men nye logins og tokenfornyelser kan fejle. Test den fejltilstand, før du gør SSO obligatorisk på tværs af stakken.
Hvornår du ikke bør selvhoste SSO
Selvhosting holder op med at være en god handel, når dit team ikke kan gendanne og drive identitetslaget med den pålidelighed, dine applikationer kræver.
Hvornår administreret identitet er sikrere
Administreret identitet er pengene værd, når omkostningen ved at drive IdP'en er højere end den kontrol, du vinder ved at selvhoste den. Tjenester som Auth0, Clerk, WorkOS og Microsoft Entra ID flytter meget af platformens tilgængelighed, patching og infrastrukturvedligeholdelse over til udbyderen.
Du ejer stadig applikationskonfiguration, rettigheder og gendannelsesplanlægning, men du er ikke længere ansvarlig for at holde selve identitetsplatformen online.
Hvornår dit team ikke kan håndtere nedetid
Hvis ingen på teamet kan gendanne IdP'en, reparere PostgreSQL, udskifte en udløbet secret eller diagnosticere en fejlende føderationsforbindelse under et nedbrud, kan selvhostet identitet være det forkerte driftsmæssige kompromis.
Fejlen er bredere end én utilgængelig applikation. Nye logins og tokenfornyelser på tværs af flere applikationer kan fejle på samme tid.
Hvornår compliance-kravene er for høje
Selvhostet identitet kan bruges i regulerede miljøer, men at køre softwaren selv producerer ikke automatisk de kontroller eller beviser, en revisor forventer. Dit team ejer stadig logning, adgangsgennemgange, backups, ændringsstyring, tilgængelighed, hændelseshåndtering og al den dokumentation, det gældende rammeværk kræver.
Selvhostet SSO er ikke et statussymbol. Hvis dit team ikke kan drive identitetslaget sikkert, kan det være den bedre tekniske beslutning at betale for administreret identitet.
Hvor Cloudzy hjælper
Cloudzy ændrer udrulningslaget; det fjerner ikke det identitetskonfigurations- og driftsarbejde, der er beskrevet ovenfor.
Problemet med manuel SSO-udrulning
En manuel SSO-udrulning betyder at forberede serveren, installere applikationen og databasen, konfigurere reverse proxyen, sætte DNS og TLS op og først derefter begynde på selve identitetskonfigurationen. Intet af det erstatter det OIDC-, SAML-, directory- eller politikarbejde, der kommer bagefter.
Ét-klik-SSO-udrulning på Cloudzy
Cloudzy har ét-klik-udrulninger til Authentik og Keycloak. Ét-klik-appen til Authentik findes på Cloudzys marketplace. Ét-klik-appen til Keycloak findes også på Cloudzys marketplace. ZITADEL er ikke på marketplace i dag, så udrul den med dens Docker Compose-opsætning på en standard-VPS. Ét-klik-installationen får basisapplikationen til at køre, mens identitetskonfiguration, DNS, backups, opgraderinger, politikker og gendannelsestest forbliver under din kontrol.
Byg på en Linux VPS med root-adgang, NVMe og AMD EPYC-kraft.
Se Linux-planerHvornår du skal bruge en separat VPS til din IdP
At hoste IdP'en sammen med dine applikationer er rimeligt til et homelab, hvor nedetid er acceptabelt. Til en forretningskritisk stak fjerner en adskilt identitetsudbyder et oplagt fælles fejldomæne: at genstarte, udtømme eller kompromittere applikationsserveren betyder ikke længere, at identitetslaget ryger med.
En separat VPS er ikke det samme som høj tilgængelighed, men den giver IdP'en sit eget ressourcebudget, sin egen vedligeholdelsesplan og sin egen gendannelsesgrænse.
Anbefalinger til VPS-dimensionering
Dimensionér hele stakken, ikke kun IdP-processen, især når PostgreSQL og en reverse proxy deler den samme VPS.
VPS-krav til Authentik
Authentiks officielle Docker Compose-dokumentation kræver en vært med mindst 2 CPU-kerner og 2 GB RAM. Det er det rigtige udgangspunkt for en lille udrulning. Giv serveren mere luft, når PostgreSQL, ekstra outposts, directory-synkronisering eller tungere logintrafik deler den samme vært.
VPS-krav til ZITADEL
ZITADELs officielle Docker Compose-udrulning kræver mindst 2 GB RAM til værten. Dimensionér en alt-i-én-VPS til ZITADEL, dens login-UI, PostgreSQL og reverse proxyen samlet frem for at se på Go-tjenesten isoleret.
VPS-krav til Keycloak
Keycloaks containerdokumentation anbefaler en hukommelsesgrænse på 2 GB til mindre produktionsklare Keycloak-udrulninger. Det tal gælder selve Keycloak-containeren, ikke en hel VPS, der også kører PostgreSQL.
Hvis Keycloak og PostgreSQL deler én VPS, er 4 GB system-RAM et fornuftigt udgangspunkt. Betragt det som praktisk vejledning for værten frem for Keycloaks officielle minimum.
VPS-krav til Authelia
Authelia offentliggør ikke et direkte sammenligneligt serverminimum på 1 GB eller 2 GB. Dimensionér værten til Authelia sammen med reverse proxyen, lagerbackenden, brugerdirectoryet og alle andre tjenester, der deler maskinen.
Authelia har generelt et mindre udrulningsaftryk end en fuld IdP sammen med PostgreSQL, men de faktiske VPS-krav afhænger af resten af stakken.
Eksempel på opsætning: Authentik med Vaultwarden
Vaultwarden tilføjede indbygget OpenID Connect SSO-understøttelse i version 1.35.0 i december 2025. Authentik er et nyttigt eksempel, fordi integrationen blotlægger de OIDC-dele, du også vil støde på med andre applikationer: redirect-URI'er, client-legitimationsoplysninger, scopes, issuer-URL'er og nødadgang.
Grundlæggende Authentik-opsætning
I Authentik:
- Opret en tilpasset e-mail-scope-mapning til Vaultwarden. Vaultwarden kræver, at scopet email returnerer enten email_verified: true eller slet ingen email_verified-værdi, mens Authentiks standard-e-mail-scope i øjeblikket returnerer false.
- Opret et OAuth2/OpenID Connect-applikations- og udbyderpar.
- Tilføj https://vault.example.com/identity/connect/oidc-signin som den strenge redirect-URI af typen Authorization.
- Vælg en hvilken som helst tilgængelig signeringsnøgle.
- Notér Client ID, Client Secret og applikationens slug.
- Sæt adgangstokenets gyldighed til mere end fem minutter.
- Tilføj Authentiks offline_access-mapning til de valgte scopes.
- Erstat standard-e-mail-mapningen med den tilpassede mapning for verificeret e-mail fra trin 1.
Grundlæggende Vaultwarden OIDC-opsætning
Brug:
DOMAIN=https://vault.example.com
SSO_ENABLED=true
SSO_AUTHORITY=https://idp.example.com/application/o/vaultwarden/
SSO_CLIENT_ID=vaultwarden
SSO_CLIENT_SECRET=<paste-secret-from-authentik>
SSO_SCOPES=email profile offline_access
SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION=false
SSO_CLIENT_CACHE_EXPIRATION=0
SSO_ONLY=false
SSO_SIGNUPS_MATCH_EMAIL=trueErstat eksempeldomænerne, applikationens slug, client-ID og client secret med værdierne fra din egen udrulning, og genstart derefter Vaultwarden.
Hvad du skal teste, før du håndhæver SSO
Lad SSO_ONLY stå på false, mens du tester login, logout, tokenfornyelse, kontomatchning og gendannelse. Test også, hvad der sker, når Authentik midlertidigt er utilgængelig.
Når både SSO og gendannelse fungerer som forventet, kan du beslutte, om det giver mening at kræve SSO ved hvert login i din udrulning.
De samme OIDC-begreber gælder for andre selvhostede applikationer, men redirect-URI'er, scopes, claims og licenser er forskellige. Tjek hver applikations SSO-dokumentation i stedet for at kopiere Vaultwarden-konfigurationen direkte.
Hvornår Authelia er bedre end en fuld IdP
Authelia bliver mere attraktiv, når applikationen slet ikke behøver at forstå identitetsudbyderen.
Autentificering i reverse proxyen
Authelia er primært designet til at beskytte applikationer i reverse proxy-laget. Du definerer adgangskontrolregler, og Authelia afgør, om en forespørgsel skal nå backend, før applikationen selv håndterer autentificering.
Beskyttelse af apps uden OIDC
Det er nyttigt til ældre interne værktøjer, dashboards og tjenester, der ikke understøtter OIDC eller SAML. I stedet for at ændre hver applikation kan du sætte autentificering foran den i reverse proxyen.
Authelia kan også fungere som OIDC-udbyder, men autentificering i reverse proxyen forbliver dens største styrke.
Brug af Authelia sammen med Authentik
Du kan bruge Authentik til applikationer, der understøtter OIDC eller SAML, og Authelia til applikationer, der har brug for autentificering i reverse proxyen.
Du behøver ikke nødvendigvis begge. Authentik understøtter også proxybaseret applikationsbeskyttelse, så at bruge Authelia ved siden af giver kun mening, når Authelias reverse proxy-workflow løser en bestemt del af din stak mere rent.
Ofte stillede spørgsmål
Er Authentik bedre end Keycloak?
Til de fleste homelabs og små selvhostede applikationsstakke er Authentik lettere at gå til. Dets admin-workflow fokuserer på applikationer, udbydere, grupper og politikker uden at blotlægge så meget IAM-kompleksitet på én gang.
Keycloak giver mere mening, når du specifikt har brug for dens dybere føderation, realm-model eller Authorization Services. Authentik er det stærkere standardvalg til enklere selvhostet SSO; Keycloak passer til miljøer, der har brug for de ekstra kontroller.
Er ZITADEL bedre end Keycloak?
ZITADEL er et bedre match, når du bygger et produkt og vil have API-drevet identitet, organisationer og multi-tenancy. Keycloak er et stærkere match, når du har brug for dens dybere autorisationsmodel, omfattende føderationskontroller eller et miljø, der allerede er bygget op omkring Keycloak.
Hvad er forskellen på Authentik og Authelia?
Authentik er en fuld identitetsudbyder bygget op omkring brugere, grupper, applikationer, udbydere, flows og politikker. Applikationer kan integrere direkte med den via protokoller som OIDC og SAML.
Authelia er centreret om autentificering og adgangskontrol i reverse proxyen. Den indeholder også en OIDC-udbyder, men beskyttelse i reverse proxyen forbliver dens primære anvendelse.
Vælg Authentik, når applikationer integrerer direkte med en IdP. Vælg Authelia, når autentificering primært skal ske, før trafikken når applikationen.
Kan jeg køre Authentik på en VPS med 1 GB?
Ikke som et understøttet udgangspunkt. Authentiks aktuelle Docker Compose-dokumentation kræver mindst 2 CPU-kerner og 2 GB RAM. Den aktuelle kerneudrulning bruger Authentik-serveren, workeren og PostgreSQL; Redis blev fjernet helt i Authentik 2025.10.
Brug 2 GB som minimumsudgangspunkt til en lille installation, og tilføj luft, når andre tjenester deler maskinen.
Understøtter Vaultwarden OIDC-SSO?
Ja. Vaultwarden tilføjede OpenID Connect SSO-understøttelse i version 1.35.0 i december 2025. Den kræver en ekstern OIDC-udbyder som Authentik, Keycloak eller ZITADEL.
Den præcise konfiguration afhænger af udbyderen. Med aktuelle Authentik-udgivelser omfatter den dokumenterede integration en tilpasset mapning for verificeret e-mail-scope, offline_access, client-legitimationsoplysninger og Authentik-applikationens issuer-URL.
Skal jeg køre min IdP på den samme VPS som mine apps?
Til et homelab, hvor nedetid er acceptabelt, kan samhosting være rimeligt. Til forretningskritiske applikationer giver en separat VPS identitetsudbyderen sit eget ressourcebudget og fjerner applikationsserveren som fælles fejldomæne.
Det skaber ikke høj tilgængelighed i sig selv, men en genstart af applikationsserveren, et ressourceproblem eller en kompromittering trækker ikke længere automatisk IdP'en med ned.
Hvilken selvhostet SSO er lettest at bruge?
Authentik er det letteste udgangspunkt for de fleste, der forbinder eksisterende selvhostede applikationer. Dets admin-grænseflade gør applikationer, udbydere, grupper og politikker lettere at gå til end Keycloaks bredere realm- og autorisationsmodel.
Authelia kan være enklere, når du kun har brug for autentificering i reverse proxyen. ZITADEL giver mere mening, når den person, der konfigurerer identitet, er en udvikler, der primært arbejder gennem API'er.
Diskussion
Kommentarer
Log ind for at deltage i diskussionen.