Authentik vs ZITADEL vs Keycloak: 어떤 셀프호스팅 SSO를 선택해야 할까?

VPS에서 Docker 컨테이너 여덟 개가 돌아가고 있습니다. Gitea, Nextcloud, Grafana, Vaultwarden, n8n, Portainer, 상태 페이지, 그리고 직접 만든 내부 앱 하나. 각각 로그인이 따로 있습니다. 매일 아침 비밀번호 관리자에서 비밀번호를 복사해 붙여넣다 보면, 싱글 사인온이 운영 비용을 감수할 만한 가치가 있는지 궁금해지기 시작합니다.

대개는 그렇습니다. 문제는 어떤 ID 공급자를 운영하느냐입니다.

Keycloak이 익숙한 기본 선택지이지만, 더 나은 선택은 스택의 모습, 관리하는 사용자 수, 그리고 이미 운영 중인 소프트웨어를 연동하는지 아니면 직접 만드는 애플리케이션에 인증을 넣는지에 따라 달라집니다.

이 셀프호스팅 SSO 비교는 Authentik, ZITADEL, Keycloak, Authelia를 배포 이후에 중요해지는 판단 기준으로 살펴봅니다. 프로토콜 지원, 사용자 관리, 개발자 워크플로, 리소스 요구 사양, 그리고 ID 공급자가 다운됐을 때 벌어지는 일입니다.

셀프호스팅 SSO가 중요한 이유

여러 애플리케이션이 같은 사람과 그룹에 의존하게 되면 개별 로그인은 더 이상 편리하지 않습니다. 셀프호스팅 ID 공급자는 계정, MFA, 그룹 소속, 접근 정책을 한곳에서 관리하게 해 주며, 애플리케이션마다 따로 설정할 필요가 없어집니다.

트레이드오프도 그만큼 중요합니다. IdP는 다른 애플리케이션이 의존하는 인프라가 됩니다. IdP를 사용할 수 없으면 새 로그인과 토큰 갱신이 실패할 수 있으므로, 백업, 복구 접근, 업그레이드, 가동 시간이 일반 셀프호스팅 앱보다 훨씬 중요해집니다.

요약

최고의 기본 선택지를 원한다면 Authentik을 선택하세요

기존 애플리케이션을 OIDC나 SAML로 연결하는 홈랩, 내부 도구 스택, 소규모 팀에게 Authentik은 가장 탄탄한 기본 선택지입니다. 관리 워크플로가 Keycloak보다 접근하기 쉽고, 여러 연동 방식을 지원하며, 공식 Docker Compose 구성은 CPU 2코어와 RAM 2GB부터 시작합니다.

앱을 만들고 있다면 ZITADEL을 선택하세요

인증이 개발 중인 제품의 일부라면 ZITADEL을 선택하세요. 조직 모델, API, 멀티테넌시, OIDC, SAML, 패스키, MFA, LDAP ID 공급자 지원은 일반적인 홈랩보다 SaaS 및 B2B 애플리케이션 팀에 더 잘 맞습니다.

엔터프라이즈 ID 기능이 필요하다면 Keycloak을 선택하세요

더 깊은 LDAP 또는 Active Directory 페더레이션, 여러 realm, 세분화된 인가 정책, 혹은 이미 Keycloak 중심으로 구축된 환경이 필요하다면 Keycloak을 선택하세요. 문서에서는 소규모 프로덕션용 Keycloak 컨테이너에 2GB 메모리 제한을 권장합니다. PostgreSQL까지 함께 돌리는 올인원 VPS에는 추가 여유가 필요합니다.

대안: 주로 로그인 장벽이 필요하다면 Authelia를 선택하세요

주된 과제가 완전한 ID 플랫폼 운영이 아니라 리버스 프록시 계층에서 애플리케이션을 보호하는 것이라면 Authelia를 선택하세요. OpenID Connect 공급자로도 동작할 수 있지만, 무게 중심은 여전히 리버스 프록시 인증에 있습니다.

SSO 도구를 고르기 전에 확인할 것

기능을 비교하기 전에, 각 도구를 이미 지원해야 하는 애플리케이션, 프로토콜, ID 소스와 대조해 보세요.

SSO가 필요한 앱은 몇 개인가?

ID 공급자가 아니라 애플리케이션에서 출발하세요. 이미 OIDC나 SAML을 지원하는 애플리케이션 여섯 개로 이루어진 스택과, 두 프로토콜을 전혀 모르는 오래된 내부 도구 스택은 전혀 다른 문제입니다. 전자는 완전한 IdP 쪽을 가리키고, 후자는 리버스 프록시 계층 인증이 필요할 수 있습니다.

앱이 OIDC나 SAML을 지원하는가?

OIDC는 현대적인 웹 애플리케이션의 일반적인 선택입니다. SAML은 엔터프라이즈 소프트웨어와 오래된 연동에서 여전히 중요합니다. LDAP는 애플리케이션이 웹 기반 SSO 흐름이 아니라 디렉터리를 기대할 때 중요할 수 있습니다. 중간에 놓을 IdP를 고르기 전에 각 애플리케이션이 실제로 무엇을 받아들이는지 확인하세요.

사용자를 관리하는가, 앱에 로그인을 구축하는가?

기존 애플리케이션을 연결하면서 대부분의 작업이 관리 인터페이스에서 이루어진다면 Authentik이 자연스러운 출발점입니다. 인증이 개발 중인 제품의 일부이고 조직, 사용자, 권한을 코드로 프로비저닝할 계획이라면 ZITADEL이 그 워크플로에 훨씬 가깝습니다.

LDAP, Active Directory, 고급 정책이 필요한가?

Authentik, ZITADEL, Keycloak 모두 어떤 형태로든 LDAP 기반 ID 소스에 연결할 수 있으므로, LDAP만으로는 더 이상 비교가 결정되지 않습니다. Keycloak은 디렉터리 페더레이션이 여러 realm, 세부 매퍼, 동기화 요구 사항, 리소스 수준 인가 정책과 결합될 때 더 흥미로워집니다.

Authentik vs ZITADEL vs Keycloak vs Authelia

네 도구는 SSO에서 겹치지만, ID에 접근하는 방향이 다릅니다. 애플리케이션 연동, 제품 ID, 엔터프라이즈 IAM, 리버스 프록시 접근입니다.

Authentik

Authentik의 핵심 배포는 서버, 워커, PostgreSQL 데이터베이스로 구성됩니다. Redis는 더 이상 스택의 일부가 아닙니다. Authentik은 2025.10 릴리스에서 이 의존성을 완전히 제거했습니다. 현재 Docker Compose 문서는 CPU 2코어와 RAM 2GB 이상인 호스트를 요구합니다.

결정적인 특징은 관리 UI입니다. Authentik의 플로 엔진, 애플리케이션 프로비저닝, 그룹 기반 정책은 Keycloak의 더 넓은 구성 모델보다 접근하기 쉽습니다. Keycloak에서 OIDC 애플리케이션을 설정한 뒤 토큰 클레임이 왜 빠졌는지 알아내느라 시간을 써 본 적이 있다면, 차이를 금방 느낄 수 있습니다.

SAML, OAuth2/OIDC, LDAP, RADIUS를 지원합니다. 셀프호스팅 앱 스택을 운영하는 홈랩이나 소규모 엔지니어링 팀에게 알맞은 기본 선택지입니다.

ZITADEL

ZITADEL은 주로 Go로 작성되었고, AGPL-3.0 라이선스이며, v4.x 릴리스 라인에 있습니다. 배포는 Go API, Next.js 로그인 UI, PostgreSQL로 구성되며, 현재 요구 사양은 PostgreSQL 14부터 18까지 지원합니다. 공식 Docker Compose 문서는 RAM 2GB 이상인 호스트를 요구합니다.

결정적인 특징은 API입니다. ZITADEL은 gRPC와 REST로 완전한 ID 표면을 노출하며 처음부터 멀티테넌트 모델 위에 만들어졌습니다. SaaS 제품을 만들면서 로그인 계층이 프로그래밍 가능하고, 자동화 가능하며, 기본적으로 멀티테넌트이기를 원한다면 ZITADEL이 대안들보다 원하는 바에 가깝습니다.

OIDC, SAML, 패스키, MFA, LDAP ID 공급자, 그리고 현재 Preview로 표시된 SCIM v2 인터페이스를 지원합니다. 조직 모델과 API 우선 워크플로 덕분에 단순한 홈랩보다 제품 팀에 더 잘 맞습니다.

Keycloak

Keycloak은 Quarkus 위에서 실행되는 Java 기반 ID 및 접근 관리 플랫폼입니다. 여기 소개한 다른 선택지보다 구성 범위가 넓으며, 특히 Realms, Clients, Roles, 사용자 페더레이션, Authorization Services가 등장하면 더욱 그렇습니다.

공식 컨테이너 문서는 소규모 프로덕션 배포에 2GB 메모리 제한을 권장합니다. 이 수치는 Keycloak 컨테이너 자체에 해당합니다. PostgreSQL이 같은 VPS를 공유한다면 호스트에 더 많은 여유를 주세요.

그 복잡성을 감수할 이유는 구체적입니다. Keycloak은 LDAP 및 Active Directory 디렉터리를 페더레이션하고, 사용자와 관리자 이벤트를 기록하며, RBAC, ABAC, 사용자 기반, 컨텍스트 기반 및 기타 정책 유형으로 세분화된 인가를 적용할 수 있습니다. 이런 제어가 필요하다면 추가 구성에는 이유가 있습니다.

Authelia

Authelia는 넷 중 가장 작습니다. Apache 2.0 라이선스, 단일 Go 바이너리이며 현재 v4.39.x입니다. 아키텍처가 나머지 셋과 다릅니다. Authelia는 리버스 프록시(nginx, Traefik, Caddy, HAProxy) 앞에 서서 요청이 백엔드에 도달해도 되는지 결정합니다.

Authelia에는 OpenID Connect 공급자도 포함되어 있습니다. 문서에서는 OIDC 구현을 아직 공개 베타로 설명하지만, 이 공급자는 Basic OP, Implicit OP, Hybrid OP, Form Post OP, Config OP 프로필에 대해 OpenID 인증을 받았습니다. OIDC 기능 범위는 Authentik이나 Keycloak이 ID 관리용으로 제공하는 것보다 좁으며, 그래서 Authelia는 리버스 프록시 인증이 주 업무일 때 여전히 가장 합리적입니다.

Authelia는 별도 섹션에서 다시 다룹니다. 짧게 말하면, Authelia의 무게 중심은 리버스 프록시 게이팅이지 완전한 ID 관리가 아닙니다.

기능 비교

아래 표는 배포와 일상 관리에 영향을 주는 차이점에 비교를 한정합니다.

어떤 도구가 어떤 스택에 맞을까?

최적의 선택은 누가 IdP를 운영하고 애플리케이션이 어떻게 연동되는지에 따라 달라집니다.

홈랩에 가장 좋은 선택

대부분의 애플리케이션이 이미 OIDC나 SAML을 지원하는 홈랩에서는 Authentik이 기본 선택입니다. Keycloak의 더 넓은 IAM 모델을 도입하지 않고도 완전한 ID 공급자를 얻을 수 있습니다. 스택 대부분이 네이티브 SSO 대신 리버스 프록시의 로그인 화면을 필요로 한다면 Authelia가 더 단순한 선택일 수 있습니다.

소규모 비즈니스 스택에 가장 좋은 선택

Authentik은 특히 Grafana, Gitea, Nextcloud, Vaultwarden 같은 도구를 위한 단일 ID 계층이 목표일 때 대부분의 소규모 내부 애플리케이션 스택에 맞습니다. 기존 디렉터리, 여러 realm, 더 깊은 인가 정책이 요구 사항에 포함되면 Keycloak이 더 매력적이 됩니다.

개발자와 SaaS 제품에 가장 좋은 선택

인증이 개발 중인 제품의 일부라면 ZITADEL이 가장 잘 맞습니다. 사용자와 테넌트를 주로 관리 패널이 아니라 애플리케이션 코드에서 프로비저닝해야 할 때 조직 모델, 멀티테넌시, API, 자동화 표면이 더 큰 의미를 갖습니다.

읽기

B2B SaaS 빌더를 위한 최고의 셀프 호스팅 CIAM

엔터프라이즈 또는 컴플라이언스 부담이 큰 팀에 가장 좋은 선택

요구 사항 목록에 복잡한 디렉터리 페더레이션, 여러 realm, 세부 인가 정책, 그리고 추가 IAM 복잡성을 운영할 수 있는 팀이 포함된다면 Keycloak이 합리적입니다. Keycloak을 셀프호스팅한다고 환경이 저절로 규정을 준수하게 되지는 않습니다. 백업, 가용성, 로깅, 접근 검토, 변경 통제는 여전히 팀의 몫입니다.

네이티브 SSO가 없는 앱에 가장 좋은 선택

요청이 애플리케이션에 도달하기 전에 인증이 이루어져야 한다면 Authelia가 가장 명확한 선택입니다. OIDC나 SAML을 자체 지원하지 않는 오래된 내부 도구, 대시보드, 서비스를 보호하는 리버스 프록시와 특히 잘 어울립니다.

SSO 셀프호스팅의 어려운 부분

SSO가 필수가 되면 구성 실수나 복구 실패가 여러 애플리케이션에 한꺼번에 영향을 줄 수 있습니다.

설치와 구성

컨테이너를 띄우는 것은 첫걸음일 뿐입니다. DNS, TLS, 리디렉션 URI, 토큰 클레임, 그룹 매핑, 이메일 발송, 복구 접근이야말로 SSO 배포가 또 하나의 Docker 앱이 아니라 인프라로 바뀌기 시작하는 지점입니다.

서버 리소스

IdP는 리소스 예산의 일부일 뿐입니다. PostgreSQL, 리버스 프록시, 워커, 비밀번호 해싱, 로그, 디렉터리 동기화는 하나의 VPS를 공유할 때 모두 CPU와 메모리를 두고 경쟁할 수 있습니다.

데이터베이스와 백업 관리

Authentik, ZITADEL, 그리고 일반적인 프로덕션 Keycloak 배포는 데이터베이스에 의존합니다. 그 데이터베이스를 서버 밖에 백업하고, 복원 방법을 문서화하고, 복원을 테스트하세요. 백업 작업의 성공은 작동하는 복구 절차와 같은 것이 아닙니다.

잠금 및 복구 위험

잘못된 리디렉션 URI, 만료된 클라이언트 시크릿, 끊어진 디렉터리 연결, 지나치게 엄격한 정책은 다른 모든 사람과 함께 관리자까지 잠가 버릴 수 있습니다. 고치려는 인증 흐름에 의존하지 않는 복구 경로를 확보해 두세요.

IdP 가용성 유지

IdP 장애가 기존 애플리케이션 세션을 모두 즉시 끝내는 것은 아닙니다. 기존 세션은 자체 토큰이나 쿠키가 만료될 때까지 이어질 수 있지만, 새 로그인과 토큰 갱신은 실패할 수 있습니다. 스택 전체에서 SSO를 필수로 만들기 전에 이 장애 모드를 테스트하세요.

SSO를 셀프호스팅하지 말아야 할 때

팀이 애플리케이션이 요구하는 신뢰성으로 ID 계층을 복구하고 운영할 수 없다면 셀프호스팅은 더 이상 좋은 거래가 아닙니다.

관리형 ID가 더 안전할 때

IdP 운영 비용이 셀프호스팅으로 얻는 통제력보다 크다면 관리형 ID에 비용을 지불할 가치가 있습니다. Auth0, Clerk, WorkOS, Microsoft Entra ID 같은 서비스는 플랫폼 가용성, 패치, 인프라 유지보수의 상당 부분을 공급자에게 넘깁니다.

애플리케이션 구성, 권한, 복구 계획은 여전히 당신의 몫이지만, ID 플랫폼 자체를 온라인으로 유지할 책임은 더 이상 없습니다.

팀이 다운타임을 감당할 수 없을 때

장애 중에 IdP를 복원하고, PostgreSQL을 고치고, 만료된 시크릿을 교체하고, 실패한 페더레이션 연결을 진단할 수 있는 사람이 팀에 아무도 없다면, ID 셀프호스팅은 잘못된 운영상의 트레이드오프일 수 있습니다.

장애는 사용할 수 없는 애플리케이션 하나에 그치지 않습니다. 여러 애플리케이션의 새 로그인과 토큰 갱신이 동시에 실패할 수 있습니다.

컴플라이언스 요구가 너무 높을 때

셀프호스팅 ID는 규제 환경에서도 사용할 수 있지만, 소프트웨어를 직접 운영한다고 감사인이 기대하는 통제나 증거가 저절로 생기지는 않습니다. 로깅, 접근 검토, 백업, 변경 관리, 가용성, 사고 대응, 그리고 해당 프레임워크가 요구하는 모든 문서는 여전히 팀의 책임입니다.

셀프호스팅 SSO는 지위의 상징이 아닙니다. 팀이 ID 계층을 안전하게 운영할 수 없다면, 관리형 ID에 비용을 지불하는 것이 더 나은 엔지니어링 결정일 수 있습니다.

Cloudzy가 도움이 되는 부분

Cloudzy가 바꾸는 것은 배포 계층입니다. 위에서 설명한 ID 구성과 운영 작업이 사라지는 것은 아닙니다.

수동 SSO 배포의 문제

수동 SSO 배포란 서버를 준비하고, 애플리케이션과 데이터베이스를 설치하고, 리버스 프록시를 구성하고, DNS와 TLS를 설정한 다음에야 ID 구성 자체를 시작하는 것을 뜻합니다. 그중 어느 것도 그 뒤에 이어지는 OIDC, SAML, 디렉터리, 정책 작업을 대체하지 못합니다.

Cloudzy의 원클릭 SSO 배포

Cloudzy는 Authentik과 Keycloak의 원클릭 배포를 제공합니다. Authentik 원클릭 앱은 Cloudzy 마켓플레이스에 있습니다. Keycloak 원클릭 앱도 Cloudzy 마켓플레이스에 있습니다. ZITADEL은 현재 마켓플레이스에 없으므로, 표준 VPS에서 Docker Compose 구성으로 배포하세요. 원클릭 설치는 기본 애플리케이션을 실행시켜 주지만, ID 구성, DNS, 백업, 업그레이드, 정책, 복구 테스트는 여전히 당신의 통제 아래 있습니다.

IdP에 별도 VPS를 써야 할 때

IdP를 애플리케이션과 같은 서버에 두는 것은 다운타임이 허용되는 홈랩에서는 합리적입니다. 비즈니스에 중요한 스택에서는 ID 공급자를 분리하면 명백한 공유 장애 도메인이 사라집니다. 애플리케이션 서버를 재시작하거나, 리소스를 고갈시키거나, 침해당해도 더 이상 ID 계층까지 함께 내려가지 않습니다.

별도 VPS가 고가용성과 같은 것은 아니지만, IdP에 고유한 리소스 예산, 유지보수 일정, 복구 경계를 부여합니다.

VPS 사양 권장

특히 PostgreSQL과 리버스 프록시가 같은 VPS를 공유할 때는 IdP 프로세스만이 아니라 스택 전체를 기준으로 사양을 정하세요.

Authentik VPS 요구 사양

Authentik의 공식 Docker Compose 문서는 CPU 2코어와 RAM 2GB 이상인 호스트를 요구합니다. 소규모 배포에는 이것이 올바른 출발점입니다. PostgreSQL, 추가 아웃포스트, 디렉터리 동기화, 더 많은 로그인 트래픽이 같은 호스트를 공유한다면 서버에 여유를 더 주세요.

ZITADEL VPS 요구 사양

ZITADEL의 공식 Docker Compose 배포는 호스트에 RAM 2GB 이상을 요구합니다. Go 서비스만 따로 보지 말고 ZITADEL, 로그인 UI, PostgreSQL, 리버스 프록시를 함께 담는 올인원 VPS 기준으로 사양을 정하세요.

Keycloak VPS 요구 사양

Keycloak의 컨테이너 문서는 소규모 프로덕션 Keycloak 배포에 2GB 메모리 제한을 권장합니다. 이 수치는 Keycloak 컨테이너 자체에 해당하며, PostgreSQL까지 돌리는 VPS 전체를 뜻하지 않습니다.

Keycloak과 PostgreSQL이 VPS 하나를 공유한다면 시스템 RAM 4GB가 합리적인 출발점입니다. 이는 Keycloak의 공식 최소 사양이 아니라 실용적인 호스트 가이드로 받아들이세요.

Authelia VPS 요구 사양

Authelia는 직접 비교할 수 있는 1GB나 2GB 같은 서버 최소 사양을 공개하지 않습니다. 리버스 프록시, 스토리지 백엔드, 사용자 디렉터리, 그리고 같은 머신을 공유하는 다른 서비스와 함께 Authelia용 호스트 사양을 정하세요.

Authelia는 일반적으로 PostgreSQL과 함께 완전한 IdP를 돌리는 것보다 배포 규모가 작지만, 실제 VPS 요구 사양은 나머지 스택에 따라 달라집니다.

설정 예시: Authentik과 Vaultwarden

Vaultwarden은 2025년 12월 버전 1.35.0에서 네이티브 OpenID Connect SSO 지원을 추가했습니다. Authentik이 유용한 예시인 이유는, 이 연동에서 다른 애플리케이션에서도 마주치게 될 OIDC 구성 요소인 리디렉션 URI, 클라이언트 자격 증명, 스코프, 발급자 URL, 복구 접근이 모두 드러나기 때문입니다.

Authentik 기본 설정

Authentik에서:

1. Vaultwarden용 사용자 지정 이메일 스코프 매핑을 만듭니다. Vaultwarden은 email 스코프가 email_verified: true를 반환하거나 email_verified 값을 아예 반환하지 않기를 요구하지만, Authentik의 기본 이메일 스코프는 현재 false를 반환합니다.
2. OAuth2/OpenID Connect 애플리케이션과 공급자 쌍을 만듭니다.
3. https://vault.example.com/identity/connect/oidc-signin을 엄격한 Authorization 리디렉션 URI로 추가합니다.
4. 사용 가능한 서명 키 아무거나 선택합니다.
5. Client ID, Client Secret, 애플리케이션 슬러그를 기록해 둡니다.
6. 액세스 토큰 유효 기간을 5분보다 길게 설정합니다.
7. Authentik의 offline_access 매핑을 선택한 스코프에 추가합니다.
8. 기본 이메일 매핑을 1단계에서 만든 사용자 지정 검증 이메일 매핑으로 교체합니다.

Vaultwarden 기본 OIDC 설정

다음을 사용하세요:

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=true

예시 도메인, 애플리케이션 슬러그, 클라이언트 ID, 클라이언트 시크릿을 자신의 배포 값으로 바꾼 뒤 Vaultwarden을 재시작합니다.

읽기

Bitwarden Password Manager 셀프 호스팅: 완전 가이드

SSO를 강제하기 전에 테스트할 것

로그인, 로그아웃, 토큰 갱신, 계정 매칭, 복구를 테스트하는 동안 SSO_ONLY는 false로 두세요. Authentik을 일시적으로 사용할 수 없을 때 어떤 일이 벌어지는지도 테스트하세요.

SSO와 복구가 모두 기대대로 동작하면, 모든 로그인에 SSO를 요구하는 것이 자신의 배포에 맞는지 결정할 수 있습니다.

같은 OIDC 개념이 다른 셀프호스팅 애플리케이션에도 적용되지만, 리디렉션 URI, 스코프, 클레임, 라이선스는 다릅니다. Vaultwarden 구성을 그대로 복사하지 말고 각 애플리케이션의 SSO 문서를 확인하세요.

완전한 IdP보다 Authelia가 나을 때

애플리케이션이 ID 공급자를 전혀 이해할 필요가 없을 때 Authelia가 더 매력적이 됩니다.

리버스 프록시 인증

Authelia는 주로 리버스 프록시 계층에서 애플리케이션을 보호하도록 설계되었습니다. 접근 제어 규칙을 정의하면, 애플리케이션 자체가 인증을 처리하기 전에 Authelia가 요청을 백엔드로 보낼지 결정합니다.

OIDC가 없는 앱 보호하기

OIDC나 SAML을 지원하지 않는 오래된 내부 도구, 대시보드, 서비스에 유용합니다. 각 애플리케이션을 수정하는 대신 리버스 프록시에서 그 앞에 인증을 둘 수 있습니다.

Authelia는 OIDC 공급자로도 동작할 수 있지만, 주된 강점은 여전히 리버스 프록시 인증입니다.

Authelia와 Authentik 함께 사용하기

OIDC나 SAML을 지원하는 애플리케이션에는 Authentik을, 리버스 프록시 인증이 필요한 애플리케이션에는 Authelia를 사용할 수 있습니다.

둘 다 꼭 필요한 것은 아닙니다. Authentik도 프록시 기반 애플리케이션 보호를 지원하므로, Authelia를 함께 쓰는 것은 Authelia의 리버스 프록시 워크플로가 스택의 특정 부분을 더 깔끔하게 해결할 때만 의미가 있습니다.

자주 묻는 질문

Authentik이 Keycloak보다 나은가?

대부분의 홈랩과 소규모 셀프호스팅 애플리케이션 스택에서는 Authentik이 접근하기 더 쉽습니다. 관리 워크플로가 애플리케이션, 공급자, 그룹, 정책에 집중되어 있어 IAM의 복잡성을 한꺼번에 많이 드러내지 않습니다.

더 깊은 페더레이션, realm 모델, Authorization Services가 특별히 필요하다면 Keycloak이 더 합리적입니다. 더 단순한 셀프호스팅 SSO에는 Authentik이 더 탄탄한 기본 선택이고, Keycloak은 그런 추가 제어가 필요한 환경에 맞습니다.

ZITADEL이 Keycloak보다 나은가?

제품을 만들면서 API 기반 ID, 조직, 멀티테넌시를 원한다면 ZITADEL이 더 잘 맞습니다. 더 깊은 인가 모델, 폭넓은 페더레이션 제어, 혹은 이미 Keycloak 중심으로 구축된 환경이 필요하다면 Keycloak이 더 잘 맞습니다.

Authentik과 Authelia의 차이는 무엇인가?

Authentik은 사용자, 그룹, 애플리케이션, 공급자, 플로, 정책을 중심으로 만들어진 완전한 ID 공급자입니다. 애플리케이션은 OIDC와 SAML 같은 프로토콜로 직접 연동할 수 있습니다.

Authelia는 리버스 프록시에서의 인증과 접근 제어가 중심입니다. OIDC 공급자도 포함되어 있지만, 주된 사용 사례는 여전히 리버스 프록시 보호입니다.

애플리케이션이 IdP와 직접 연동된다면 Authentik을 선택하세요. 인증이 주로 트래픽이 애플리케이션에 도달하기 전에 이루어져야 한다면 Authelia를 선택하세요.

1GB VPS에서 Authentik을 돌릴 수 있는가?

지원되는 출발점으로는 아닙니다. Authentik의 현재 Docker Compose 문서는 CPU 2코어와 RAM 2GB 이상을 요구합니다. 현재 핵심 배포는 Authentik 서버, 워커, PostgreSQL을 사용하며, Redis는 Authentik 2025.10에서 완전히 제거되었습니다.

소규모 설치에는 2GB를 최소 출발점으로 삼고, 다른 서비스가 머신을 공유하면 여유를 더하세요.

Vaultwarden은 OIDC SSO를 지원하는가?

예. Vaultwarden은 2025년 12월 버전 1.35.0에서 OpenID Connect SSO 지원을 추가했습니다. Authentik, Keycloak, ZITADEL 같은 외부 OIDC 공급자가 필요합니다.

정확한 구성은 공급자에 따라 다릅니다. 현재 Authentik 릴리스에서는 문서화된 연동에 사용자 지정 검증 이메일 스코프 매핑, offline_access, 클라이언트 자격 증명, Authentik 애플리케이션 발급자 URL이 포함됩니다.

IdP를 앱과 같은 VPS에서 돌려야 할까?

다운타임이 허용되는 홈랩이라면 같은 서버에 두는 것도 합리적일 수 있습니다. 비즈니스에 중요한 애플리케이션이라면 별도 VPS가 ID 공급자에게 고유한 리소스 예산을 주고 애플리케이션 서버를 공유 장애 도메인에서 빼냅니다.

그것만으로 고가용성이 생기지는 않지만, 애플리케이션 서버 재시작, 리소스 문제, 침해가 더 이상 IdP를 자동으로 함께 무너뜨리지는 않습니다.

가장 사용하기 쉬운 셀프호스팅 SSO는?

기존 셀프호스팅 애플리케이션을 연결하는 대부분의 사람에게 Authentik이 가장 쉬운 출발점입니다. 관리 UI 덕분에 애플리케이션, 공급자, 그룹, 정책이 Keycloak의 더 넓은 realm 및 인가 모델보다 다루기 쉽습니다.

리버스 프록시 인증만 필요하다면 Authelia가 더 단순할 수 있습니다. ID를 설정하는 사람이 주로 API로 작업하는 개발자라면 ZITADEL이 더 합리적입니다.