Nyolc Docker-konténer fut a VPS-én. Gitea, Nextcloud, Grafana, Vaultwarden, n8n, Portainer, egy állapotoldal és egy saját fejlesztésű belső alkalmazás. Mindegyiknek külön bejelentkezése van. Minden reggel jelszavakat másolgat a jelszókezelőjéből, és kezdi azon gondolkodni, megéri-e az egyszeri bejelentkezés az üzemeltetési költséget.
Általában megéri. A kérdés az, melyik identitásszolgáltatót futtassa.
A Keycloak az ismerős alapértelmezés, de a jobb választás attól függ, hogyan néz ki a stackje, hány felhasználót kezel, és meglévő szoftvert integrál-e, vagy saját alkalmazásaiba épít hitelesítést.
Ez a saját üzemeltetésű SSO-összehasonlítás az Authentiket, a ZITADEL-t, a Keycloakot és az Autheliát azokon a döntéseken keresztül vizsgálja, amelyek a telepítés után számítanak: protokolltámogatás, felhasználókezelés, fejlesztői munkafolyamat, erőforrásigény, és mi történik, ha az identitásszolgáltató leáll.
Miért számít a saját üzemeltetésű SSO
Amint több alkalmazás ugyanazoktól a személyektől és csoportoktól függ, a külön bejelentkezések megszűnnek kényelmesnek lenni. Egy saját üzemeltetésű identitásszolgáltató egyetlen helyet ad a fiókok, az MFA, a csoporttagság és a hozzáférési szabályzatok kezelésére, ahelyett hogy ezeket minden alkalmazásban külön állítaná be.
A másik oldal ugyanilyen fontos: az IdP olyan infrastruktúrává válik, amelytől más alkalmazások függenek. Ha nem elérhető, az új bejelentkezések és a tokenfrissítések meghiúsulhatnak, ezért a mentések, a helyreállítási hozzáférés, a frissítések és a rendelkezésre állás itt többet számítanak, mint egy hétköznapi saját üzemeltetésű alkalmazásnál.
Röviden
Válassza az Authentiket, ha a legjobb alapértelmezett megoldást keresi
Homelabhoz, belső eszközstackhez vagy olyan kis csapatnak, amely meglévő alkalmazásokat köt be OIDC-n vagy SAML-en keresztül, az Authentik a legerősebb alapértelmezés. Adminisztrációs munkafolyamata könnyebben megközelíthető, mint a Keycloaké, több integrációs módot támogat, és hivatalos Docker Compose-beállítása 2 CPU-magtól és 2 GB RAM-tól indul.
Válassza a ZITADEL-t, ha alkalmazásokat épít
Válassza a ZITADEL-t, ha a hitelesítés az épített termék része. Szervezeti modellje, API-jai, többbérlős felépítése, az OIDC, a SAML, a passkey-k, az MFA és az LDAP identitásszolgáltatók támogatása inkább SaaS- és B2B-alkalmazáscsapatoknak való, mint egy tipikus homelabnak.
Válassza a Keycloakot, ha vállalati identitásfunkciókra van szüksége
Válassza a Keycloakot, ha mélyebb LDAP- vagy Active Directory-föderációra, több realmre, finomhangolt engedélyezési szabályzatokra vagy egy már Keycloak köré épült környezetre van szüksége. A dokumentáció 2 GB memóriakorlátot javasol a kisebb, éles üzemre kész Keycloak-konténerekhez; egy PostgreSQL-t is futtató, mindent egyben VPS-nek további tartalék kell.
Alternatíva: válassza az Autheliát, ha főleg egy bejelentkezési falra van szüksége
Válassza az Autheliát, ha a fő problémája az alkalmazások védelme a fordított proxy rétegében, nem pedig egy teljes identitásplatform futtatása. OpenID Connect-szolgáltatóként is működhet, de a fordított proxyn végzett hitelesítés marad a súlypontja.
Mit ellenőrizzen, mielőtt SSO-eszközt választ
Mielőtt funkciókat hasonlítana össze, vesse össze az egyes eszközöket azokkal az alkalmazásokkal, protokollokkal és identitásforrásokkal, amelyeket már most támogatnia kell.
Hány alkalmazásnak kell SSO?
Az alkalmazásokból induljon ki, ne az identitásszolgáltatóból. Egy hat, már OIDC-t vagy SAML-t támogató alkalmazásból álló stack más probléma, mint egy régi belső eszközökből álló, amely egyik protokollról sem tud semmit. Az első eset teljes IdP-re mutat. A másodiknak a fordított proxy rétegében lehet szüksége hitelesítésre.
Támogatják az alkalmazásai az OIDC-t vagy a SAML-t?
Az OIDC a szokásos választás modern webalkalmazásokhoz. A SAML továbbra is számít a vállalati szoftverekben és a régebbi integrációkban. Az LDAP akkor számíthat, ha az alkalmazás címtárat vár webalapú SSO-folyamat helyett. Ellenőrizze, mit fogad el ténylegesen az egyes alkalmazás, mielőtt kiválasztja a középre kerülő IdP-t.
Felhasználókat kezel, vagy bejelentkezést épít egy alkalmazásba?
Ha a munkája nagy része egy adminisztrációs felületen zajlik majd, miközben meglévő alkalmazásokat köt be, az Authentik a természetes kiindulópont. Ha a hitelesítés az épített termék része, és a szervezeteket, felhasználókat és jogosultságokat kódból tervezi létrehozni, a ZITADEL sokkal közelebb áll ehhez a munkafolyamathoz.
Szüksége van LDAP-ra, Active Directoryra vagy haladó szabályzatokra?
Az Authentik, a ZITADEL és a Keycloak mind képes valamilyen formában LDAP-alapú identitásforrásokhoz kapcsolódni, így önmagában az LDAP már nem dönti el az összehasonlítást. A Keycloak akkor válik érdekesebbé, ha a címtárföderáció több realmmel, részletes leképezőkkel, szinkronizálási követelményekkel vagy erőforrásszintű engedélyezési szabályzatokkal párosul.
Authentik vs ZITADEL vs Keycloak vs Authelia
A négy eszköz átfedésben van az SSO terén, de más-más irányból közelíti meg az identitást: alkalmazásintegráció, termékidentitás, vállalati IAM és fordított proxyn keresztüli hozzáférés.
Authentik
Az Authentik alaptelepítése egy szerverből, egy workerből és egy PostgreSQL-adatbázisból áll. A Redis már nem része a stacknek: az Authentik a 2025.10-es kiadásban teljesen eltávolította ezt a függőséget. A jelenlegi Docker Compose-dokumentáció legalább 2 CPU-maggal és 2 GB RAM-mal rendelkező gépet ír elő.
A meghatározó vonás az adminisztrációs felület. Az Authentik folyamatmotorja, alkalmazás-kiosztása és csoportalapú szabályzatai könnyebben megközelíthetők, mint a Keycloak szélesebb konfigurációs modellje. Ha valaha beállított egy OIDC-alkalmazást a Keycloakban, majd időt töltött azzal, hogy kiderítse, miért hiányoznak a token claimjei, a különbség gyorsan feltűnik.
Támogatja a SAML-t, az OAuth2/OIDC-t, az LDAP-ot és a RADIUS-t. Ez a megfelelő alapértelmezés egy homelabnak vagy egy saját üzemeltetésű alkalmazásstacket futtató kis mérnökcsapatnak.
ZITADEL
A ZITADEL elsősorban Go nyelven íródott, AGPL-3.0 licenc alatt áll, és a v4.x kiadási vonalon jár. A telepítés egy Go API-ból, egy Next.js bejelentkezési felületből és PostgreSQL-ből áll, a jelenlegi követelmények pedig a PostgreSQL 14-től 18-ig terjedő verzióit támogatják. A hivatalos Docker Compose-dokumentáció legalább 2 GB RAM-mal rendelkező gépet ír elő.
A meghatározó vonás az API. A ZITADEL teljes identitásfelületet tesz elérhetővé gRPC-n és REST-en keresztül, és kezdettől többbérlős modellre épül. Ha SaaS-terméket épít, és azt szeretné, hogy a bejelentkezési réteg programozható, automatizálható és alapból többbérlős legyen, a ZITADEL közelebb áll ahhoz, amit keres, mint az alternatívák.
Támogatja az OIDC-t, a SAML-t, a passkey-ket, az MFA-t, az LDAP identitásszolgáltatókat és egy jelenleg Preview jelölésű SCIM v2 felületet. Szervezeti modellje és API-központú munkafolyamata miatt inkább termékcsapatoknak való, mint egy egyszerű homelabnak.
Keycloak
A Keycloak egy Java alapú identitás- és hozzáférés-kezelő platform, amely Quarkuson fut. Konfigurációs felülete nagyobb, mint az itt bemutatott többi lehetőségé, különösen amint a Realms, a Clients, a Roles, a felhasználói föderáció és az Authorization Services is képbe kerül.
Hivatalos konténerdokumentációja 2 GB memóriakorlátot javasol a kisebb, éles üzemre kész telepítésekhez. Ez az érték magára a Keycloak-konténerre vonatkozik; ha a PostgreSQL ugyanazon a VPS-en fut, adjon a gépnek több tartalékot.
Az ok, amiért érdemes vállalni ezt az összetettséget, kézzelfogható. A Keycloak képes LDAP- és Active Directory-címtárakat föderálni, felhasználói és adminisztrátori eseményeket naplózni, valamint finomhangolt engedélyezést érvényesíteni RBAC, ABAC, felhasználóalapú, kontextusalapú és más szabályzattípusokkal. Ha szüksége van ezekre az ellenőrzésekre, a plusz konfigurációnak van értelme.
Authelia
Az Authelia a négy közül a legkisebb: Apache 2.0 licenc, egyetlen Go bináris, jelenleg a v4.39.x verziónál. Az architektúra eltér a másik háromtól: az Authelia egy fordított proxy (nginx, Traefik, Caddy, HAProxy) előtt áll, és eldönti, hogy a kérések eljuthatnak-e a háttérrendszerhez.
Az Authelia OpenID Connect-szolgáltatót is tartalmaz. Dokumentációja az OIDC-megvalósítást még nyílt bétaként írja le, de a szolgáltató OpenID-tanúsítvánnyal rendelkezik a Basic OP, Implicit OP, Hybrid OP, Form Post OP és Config OP profilokhoz. OIDC-funkciókészlete szűkebb annál, amit az Authentik vagy a Keycloak nyújt identitáskezelésre, ezért az Authelia továbbra is akkor a legésszerűbb, ha a fordított proxyn végzett hitelesítés a fő feladat.
Az Autheliához külön szakaszban térünk vissza. Röviden: az Authelia súlypontja a fordított proxyn végzett hozzáférés-szűrés, nem a teljes identitáskezelés.
Funkciók összehasonlítása
Az alábbi táblázat azokra a különbségekre szűkíti az összehasonlítást, amelyek a telepítést és a napi adminisztrációt érintik.
| Funkció | Authentik | ZITADEL | Keycloak | Authelia |
|---|---|---|---|---|
| Támogatott protokollok | OAuth2/OIDC, SAML, LDAP, RADIUS, proxyhitelesítés | OAuth2/OIDC, SAML, LDAP identitásszolgáltató, SCIM v2 Preview | OAuth2/OIDC, SAML, LDAP- és Active Directory-föderáció | OIDC-szolgáltató plusz fordított proxyn végzett hitelesítés |
| Felhasználó- és csoportkezelés | Felhasználók, csoportok, szabályzatok, folyamatok, alkalmazáskötések | Felhasználók, szervezetek, projektek, szerepkörök, jogosultságok | Felhasználók, csoportok, realmek, kliensszerepkörök, realmszerepkörök, föderáció | Könnyű felhasználókezelés, jellemzően fájlokra vagy LDAP-ra építve |
| Fejlesztői élmény | Van API, de a fő erősség az adminisztrációs felület | API-központú, erős szervezeti és többbérlős modell | Kiforrott REST API-k egy nagyobb, megtanulandó IAM-modellel | Elsősorban konfigurációvezérelt |
| Vállalati funkciók | Szabályzatok, föderáció, outpostok, alkalmazás-hozzáférési ellenőrzések | Szervezetek, projektek, passkey-k, föderáció, SCIM v2 Preview | Mély föderáció, több realm, események, Authorization Services | Hozzáférés-vezérlési szabályok és erős fordítottproxy-integráció |
| Beállítás egyszerűsége | Könnyebb kiindulópont a legtöbb saját üzemeltetésű alkalmazásstackhez | Akkor a legjobb, ha a csapat API-kban és termékidentitásban gondolkodik | Több fogalom és konfiguráció, de mélyebb ellenőrzés | A legegyszerűbb, ha a feladat főként a fordított proxyn végzett hitelesítés |
| Erőforrás-ajánlás | Hivatalos Compose-minimum: 2 CPU-mag és 2 GB RAM | Hivatalos Compose-minimum a gépre: 2 GB RAM | Ajánlott konténermemória 2 GB a kisebb éles telepítésekhez | Nincs közvetlenül összevethető hivatalos RAM-minimum |
Melyik eszköz melyik stackhez való?
A legjobb választás attól függ, ki üzemelteti az IdP-t, és hogyan integrálódnak hozzá az alkalmazások.
A legjobb lehetőség homelabhoz
Az Authentik az alapértelmezés olyan homelabhoz, ahol az alkalmazások többsége már támogatja az OIDC-t vagy a SAML-t. Teljes identitásszolgáltatót ad anélkül, hogy át kellene vennie a Keycloak szélesebb IAM-modelljét. Ha a stack nagy részének natív SSO helyett bejelentkezési képernyőre van szüksége a fordított proxyn, az Authelia lehet az egyszerűbb választás.
A legjobb lehetőség kisvállalati stackhez
Az Authentik a legtöbb kis belső alkalmazásstackhez illik, különösen ha a cél egyetlen identitásréteg olyan eszközökhöz, mint a Grafana, a Gitea, a Nextcloud és a Vaultwarden. A Keycloak akkor válik vonzóbbá, ha meglévő címtár, több realm vagy mélyebb engedélyezési szabályzatok is a követelmények részét képezik.
A legjobb lehetőség fejlesztőknek és SaaS-termékekhez
A ZITADEL a legjobb választás, ha a hitelesítés az épített termék része. Szervezeti modellje, többbérlős felépítése, API-jai és automatizálási felülete akkor a legésszerűbb, ha a felhasználókat és bérlőket alkalmazáskódból kell létrehozni, nem elsősorban adminisztrációs panelen keresztül.
A legjobb lehetőség vállalati vagy szigorú megfelelőségi igényű csapatoknak
A Keycloak akkor ésszerű, ha a követelménylista összetett címtárföderációt, több realmet, részletes engedélyezési szabályzatokat és olyan csapatot tartalmaz, amely képes üzemeltetni a plusz IAM-összetettséget. A Keycloak saját üzemeltetése önmagában nem tesz megfelelővé egy környezetet; a mentések, a rendelkezésre állás, a naplózás, a hozzáférés-felülvizsgálatok és a változáskezelés továbbra is az Ön csapatának feladata.
A legjobb lehetőség natív SSO nélküli alkalmazásokhoz
Az Authelia a legegyértelműbb választás, ha a hitelesítésnek azelőtt kell megtörténnie, hogy a kérések elérnék az alkalmazást. Különösen jól működik olyan fordított proxykkal, amelyek régebbi belső eszközöket, irányítópultokat és olyan szolgáltatásokat védenek, amelyek maguk nem támogatják az OIDC-t vagy a SAML-t.
Az SSO saját üzemeltetésének nehéz része
Amint az SSO kötelező, egy konfigurációs hiba vagy egy sikertelen helyreállítás egyszerre több alkalmazást érinthet.
Telepítés és konfigurálás
A konténerek elindítása csak az első lépés. A DNS, a TLS, az átirányítási URI-k, a token claimek, a csoportleképezések, az e-mail-kézbesítés és a helyreállítási hozzáférés azok a pontok, ahol egy SSO-telepítés egy újabb Docker-alkalmazás helyett infrastruktúrává kezd válni.
Szervererőforrások
Az IdP csak egy része az erőforrás-költségvetésnek. A PostgreSQL, a fordított proxyk, a workerek, a jelszóhashelés, a naplók és a címtár-szinkronizálás mind versenyezhetnek a CPU-ért és a memóriáért, ha egy VPS-en osztoznak.
Adatbázis- és mentéskezelés
Az Authentik, a ZITADEL és a szokásos éles Keycloak-telepítések adatbázistól függenek. Mentse ezt az adatbázist a szerveren kívülre, dokumentálja a visszaállítás módját, és tesztelje a visszaállítást. Egy sikeres mentési feladat nem ugyanaz, mint egy működő helyreállítási eljárás.
Kizárási és helyreállítási kockázatok
Egy rossz átirányítási URI, egy lejárt klienstitok, egy megszakadt címtárkapcsolat vagy egy túl szigorú szabályzat az adminisztrátorokat is kizárhatja mindenki mással együtt. Tartson fenn olyan helyreállítási utat, amely nem függ attól a hitelesítési folyamattól, amelyet éppen javítani próbál.
Az IdP elérhetőségének fenntartása
Egy IdP-kiesés nem feltétlenül zár le azonnal minden meglévő alkalmazás-munkamenetet. A meglévő munkamenetek folytatódhatnak, amíg a saját tokenjeik vagy sütijeik le nem járnak, de az új bejelentkezések és a tokenfrissítések meghiúsulhatnak. Tesztelje ezt a hibamódot, mielőtt az SSO-t az egész stackben kötelezővé teszi.
Mikor ne üzemeltesse saját maga az SSO-t
A saját üzemeltetés akkor szűnik meg jó üzletnek lenni, ha a csapata nem tudja olyan megbízhatósággal helyreállítani és üzemeltetni az identitásréteget, amilyet az alkalmazásai megkövetelnek.
Mikor biztonságosabb a felügyelt identitás
A felügyelt identitásért akkor érdemes fizetni, ha az IdP üzemeltetésének költsége nagyobb, mint a saját üzemeltetéssel nyert kontroll. Az olyan szolgáltatások, mint az Auth0, a Clerk, a WorkOS és a Microsoft Entra ID, a platform rendelkezésre állásának, a javítások telepítésének és az infrastruktúra karbantartásának nagy részét a szolgáltatóra hárítják.
Az alkalmazáskonfiguráció, a jogosultságok és a helyreállítás tervezése továbbra is az Öné, de már nem Ön felel azért, hogy maga az identitásplatform elérhető maradjon.
Mikor nem bírja a csapata a leállást
Ha egy kiesés alatt a csapatban senki sem tudja helyreállítani az IdP-t, megjavítani a PostgreSQL-t, kicserélni egy lejárt titkot vagy diagnosztizálni egy hibás föderációs kapcsolatot, az identitás saját üzemeltetése rossz üzemeltetési kompromisszum lehet.
A hiba több, mint egyetlen elérhetetlen alkalmazás. Több alkalmazásban is egyszerre hiúsulhatnak meg az új bejelentkezések és a tokenfrissítések.
Mikor túl magasak a megfelelőségi igények
A saját üzemeltetésű identitás használható szabályozott környezetekben, de a szoftver saját futtatása nem hozza létre automatikusan azokat az ellenőrzéseket vagy bizonyítékokat, amelyeket egy auditor elvár. A csapata továbbra is felel a naplózásért, a hozzáférés-felülvizsgálatokért, a mentésekért, a változáskezelésért, a rendelkezésre állásért, az incidenskezelésért és minden dokumentációért, amelyet az alkalmazandó keretrendszer megkövetel.
A saját üzemeltetésű SSO nem státuszszimbólum. Ha a csapata nem tudja biztonságosan üzemeltetni az identitásréteget, a felügyelt identitásért fizetni jobb mérnöki döntés lehet.
Miben segít a Cloudzy
A Cloudzy a telepítési réteget változtatja meg; nem szünteti meg a fent leírt identitáskonfigurációs és üzemeltetési munkát.
A kézi SSO-telepítés problémája
A kézi SSO-telepítés a szerver előkészítését, az alkalmazás és az adatbázis telepítését, a fordított proxy konfigurálását, a DNS és a TLS beállítását jelenti, és csak ezután kezdődhet maga az identitáskonfiguráció. Ezek egyike sem helyettesíti az utána következő OIDC-, SAML-, címtár- vagy szabályzatmunkát.
Egykattintásos SSO-telepítés a Cloudzyn
A Cloudzy egykattintásos telepítést kínál az Authentikhez és a Keycloakhoz. Az egykattintásos Authentik-alkalmazás elérhető a Cloudzy piacterén. Az egykattintásos Keycloak-alkalmazás szintén elérhető a Cloudzy piacterén. A ZITADEL jelenleg nincs a piactéren, ezért azt a saját Docker Compose-beállításával telepítse egy szabványos VPS-re. Az egykattintásos telepítés az alapalkalmazást indítja el, míg az identitáskonfiguráció, a DNS, a mentések, a frissítések, a szabályzatok és a helyreállítási tesztek az Ön kezében maradnak.
Építkezz Linux VPS-en root hozzáféréssel, NVMe-vel és AMD EPYC teljesítménnyel.
Linux csomagok megtekintéseMikor használjon külön VPS-t az IdP-hez
Az IdP és az alkalmazások közös gépen futtatása ésszerű olyan homelabban, ahol a leállás elfogadható. Üzletileg kritikus stack esetén az identitásszolgáltató különválasztása egy nyilvánvaló közös hibatartományt szüntet meg: az alkalmazásszerver újraindítása, kimerítése vagy kompromittálása többé nem rántja magával az identitásréteget.
A külön VPS nem azonos a magas rendelkezésre állással, de saját erőforrás-költségvetést, karbantartási ütemtervet és helyreállítási határt ad az IdP-nek.
VPS-méretezési ajánlások
Az egész stacket méretezze, ne csak az IdP-folyamatot, különösen ha a PostgreSQL és egy fordított proxy ugyanazon a VPS-en osztozik.
Az Authentik VPS-igényei
Az Authentik hivatalos Docker Compose-dokumentációja legalább 2 CPU-maggal és 2 GB RAM-mal rendelkező gépet ír elő. Kis telepítéshez ez a helyes kiindulópont. Adjon a szervernek több tartalékot, ha a PostgreSQL, további outpostok, címtár-szinkronizálás vagy nagyobb bejelentkezési forgalom osztozik ugyanazon a gépen.
A ZITADEL VPS-igényei
A ZITADEL hivatalos Docker Compose-telepítése legalább 2 GB RAM-ot ír elő a gépre. A mindent egyben VPS-t a ZITADEL-hez, annak bejelentkezési felületéhez, a PostgreSQL-hez és a fordított proxyhoz együtt méretezze, ahelyett hogy a Go-szolgáltatást önmagában nézné.
A Keycloak VPS-igényei
A Keycloak konténerdokumentációja 2 GB memóriakorlátot javasol a kisebb, éles üzemre kész Keycloak-telepítésekhez. Ez az érték magára a Keycloak-konténerre vonatkozik, nem egy teljes VPS-re, amely PostgreSQL-t is futtat.
Ha a Keycloak és a PostgreSQL egy VPS-en osztozik, 4 GB rendszer-RAM ésszerű kiindulópont. Ezt gyakorlati gépméretezési iránymutatásnak tekintse, ne a Keycloak hivatalos minimumának.
Az Authelia VPS-igényei
Az Authelia nem tesz közzé közvetlenül összevethető 1 GB-os vagy 2 GB-os szerverminimumot. A gépet az Autheliához a fordított proxyval, a tárolóháttérrel, a felhasználói címtárral és a gépen osztozó minden más szolgáltatással együtt méretezze.
Az Authelia telepítési lábnyoma általában kisebb, mint egy teljes IdP-é PostgreSQL-lel együtt, de a tényleges VPS-igény a stack többi részétől függ.
Példa beállításra: Authentik Vaultwardennel
A Vaultwarden az 1.35.0 verzióban, 2025 decemberében kapott natív OpenID Connect SSO-támogatást. Az Authentik azért hasznos példa, mert az integráció megmutatja azokat az OIDC-elemeket, amelyekkel más alkalmazásoknál is találkozni fog: átirányítási URI-k, klienshitelesítő adatok, hatókörök, kibocsátó URL-ek és helyreállítási hozzáférés.
Az Authentik alapbeállítása
Az Authentikben:
- Hozzon létre egyéni e-mail-hatókör-leképezést a Vaultwardenhez. A Vaultwarden megköveteli, hogy az email hatókör vagy email_verified: true értéket adjon vissza, vagy egyáltalán ne adjon vissza email_verified értéket, míg az Authentik alapértelmezett e-mail-hatóköre jelenleg false értéket ad.
- Hozzon létre egy OAuth2/OpenID Connect alkalmazás- és szolgáltatópárt.
- Adja hozzá a https://vault.example.com/identity/connect/oidc-signin címet szigorú, Authorization típusú átirányítási URI-ként.
- Válasszon ki egy tetszőleges elérhető aláírókulcsot.
- Jegyezze fel a Client ID-t, a Client Secretet és az alkalmazás slugját.
- Állítsa a hozzáférési token érvényességét öt percnél hosszabbra.
- Adja hozzá az Authentik offline_access leképezését a kiválasztott hatókörökhöz.
- Cserélje le az alapértelmezett e-mail-leképezést az 1. lépésben létrehozott egyéni, ellenőrzött e-mail-leképezésre.
A Vaultwarden OIDC-alapbeállítása
Használja ezt:
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=trueCserélje le a példadomaineket, az alkalmazás slugját, a kliensazonosítót és a klienstitkot a saját telepítése értékeire, majd indítsa újra a Vaultwardent.
Mit teszteljen, mielőtt kötelezővé teszi az SSO-t
Hagyja az SSO_ONLY értékét false-on, amíg teszteli a bejelentkezést, a kijelentkezést, a tokenfrissítést, a fiókpárosítást és a helyreállítást. Tesztelje azt is, mi történik, ha az Authentik átmenetileg nem elérhető.
Ha az SSO és a helyreállítás is a várt módon működik, eldöntheti, van-e értelme a telepítésében minden bejelentkezéshez SSO-t megkövetelni.
Ugyanezek az OIDC-fogalmak más saját üzemeltetésű alkalmazásokra is érvényesek, de az átirányítási URI-k, a hatókörök, a claimek és a licencek eltérnek. Nézze meg az egyes alkalmazások SSO-dokumentációját, ahelyett hogy a Vaultwarden-konfigurációt közvetlenül lemásolná.
Mikor jobb az Authelia egy teljes IdP-nél
Az Authelia akkor válik vonzóbbá, ha az alkalmazásnak egyáltalán nem kell értenie az identitásszolgáltatót.
Hitelesítés a fordított proxyn
Az Authelia elsősorban arra készült, hogy az alkalmazásokat a fordított proxy rétegében védje. Ön hozzáférés-vezérlési szabályokat határoz meg, az Authelia pedig eldönti, hogy egy kérés eljusson-e a háttérrendszerhez, még mielőtt maga az alkalmazás kezelné a hitelesítést.
OIDC nélküli alkalmazások védelme
Ez régebbi belső eszközöknél, irányítópultoknál és olyan szolgáltatásoknál hasznos, amelyek nem támogatják az OIDC-t vagy a SAML-t. Ahelyett, hogy minden alkalmazást módosítana, a hitelesítést elé teheti a fordított proxyn.
Az Authelia OIDC-szolgáltatóként is működhet, de a fordított proxyn végzett hitelesítés marad a fő erőssége.
Az Authelia használata az Authentikkel együtt
Az Authentiket használhatja az OIDC-t vagy SAML-t támogató alkalmazásokhoz, az Autheliát pedig azokhoz, amelyeknek a fordított proxyn van szükségük hitelesítésre.
Nem feltétlenül kell mindkettő. Az Authentik is támogatja a proxyalapú alkalmazásvédelmet, így az Authelia mellette csak akkor ésszerű, ha az Authelia fordítottproxy-munkafolyamata a stack egy adott részét tisztábban oldja meg.
Gyakran ismételt kérdések
Jobb az Authentik a Keycloaknál?
A legtöbb homelab és kis saját üzemeltetésű alkalmazásstack esetén az Authentik könnyebben megközelíthető. Adminisztrációs munkafolyamata az alkalmazásokra, szolgáltatókra, csoportokra és szabályzatokra összpontosít, anélkül hogy egyszerre annyi IAM-összetettséget mutatna.
A Keycloak akkor ésszerűbb, ha kifejezetten a mélyebb föderációjára, realm-modelljére vagy az Authorization Servicesre van szüksége. Az Authentik az erősebb alapértelmezés egyszerűbb saját üzemeltetésű SSO-hoz; a Keycloak olyan környezetekhez illik, amelyeknek ezekre a további ellenőrzésekre van szükségük.
Jobb a ZITADEL a Keycloaknál?
A ZITADEL akkor jobb választás, ha terméket épít, és API-vezérelt identitást, szervezeteket és többbérlős felépítést szeretne. A Keycloak akkor jobb, ha a mélyebb engedélyezési modelljére, kiterjedt föderációs lehetőségeire vagy egy már Keycloak köré épült környezetre van szüksége.
Mi a különbség az Authentik és az Authelia között?
Az Authentik teljes identitásszolgáltató, amely felhasználók, csoportok, alkalmazások, szolgáltatók, folyamatok és szabályzatok köré épül. Az alkalmazások közvetlenül integrálódhatnak hozzá olyan protokollokon keresztül, mint az OIDC és a SAML.
Az Authelia a fordított proxyn végzett hitelesítésre és hozzáférés-vezérlésre összpontosít. OIDC-szolgáltatót is tartalmaz, de a fordított proxyn nyújtott védelem marad az elsődleges felhasználási esete.
Válassza az Authentiket, ha az alkalmazások közvetlenül integrálódnak egy IdP-hez. Válassza az Autheliát, ha a hitelesítésnek főként azelőtt kell megtörténnie, hogy a forgalom elérné az alkalmazást.
Futtathatom az Authentiket 1 GB-os VPS-en?
Támogatott kiindulópontként nem. Az Authentik jelenlegi Docker Compose-dokumentációja legalább 2 CPU-magot és 2 GB RAM-ot ír elő. A jelenlegi alaptelepítés az Authentik-szervert, a workert és a PostgreSQL-t használja; a Redist az Authentik 2025.10-ben teljesen eltávolították.
Kis telepítéshez 2 GB-ot tekintsen minimális kiindulópontnak, és adjon hozzá tartalékot, ha más szolgáltatások is osztoznak a gépen.
Támogatja a Vaultwarden az OIDC SSO-t?
Igen. A Vaultwarden az 1.35.0 verzióban, 2025 decemberében kapott OpenID Connect SSO-támogatást. Külső OIDC-szolgáltatót igényel, például Authentiket, Keycloakot vagy ZITADEL-t.
A pontos konfiguráció a szolgáltatótól függ. A jelenlegi Authentik-kiadásokkal a dokumentált integráció egyéni, ellenőrzött e-mail-hatókör-leképezést, offline_access-t, klienshitelesítő adatokat és az Authentik-alkalmazás kibocsátó URL-jét tartalmazza.
Ugyanazon a VPS-en futtassam az IdP-t, mint az alkalmazásaimat?
Olyan homelabban, ahol a leállás elfogadható, a közös gépen futtatás ésszerű lehet. Üzletileg kritikus alkalmazásoknál egy külön VPS saját erőforrás-költségvetést ad az identitásszolgáltatónak, és kiveszi az alkalmazásszervert a közös hibatartományból.
Ez önmagában nem teremt magas rendelkezésre állást, de egy alkalmazásszerver-újraindítás, erőforrás-probléma vagy kompromittálódás többé nem rántja magával automatikusan az IdP-t.
Melyik saját üzemeltetésű SSO a legkönnyebben használható?
Az Authentik a legkönnyebb kiindulópont a legtöbb olyan felhasználónak, aki meglévő saját üzemeltetésű alkalmazásokat köt be. Adminisztrációs felülete az alkalmazásokat, szolgáltatókat, csoportokat és szabályzatokat könnyebben megközelíthetővé teszi, mint a Keycloak szélesebb realm- és engedélyezési modellje.
Az Authelia egyszerűbb lehet, ha csak a fordított proxyn van szüksége hitelesítésre. A ZITADEL akkor ésszerűbb, ha az identitást konfiguráló személy egy elsősorban API-kon keresztül dolgozó fejlesztő.
Beszélgetés
Hozzászólások
Jelentkezzen be a beszélgetéshez.