Guía de despliegue

Authentik, Authelia o Keycloak: elegir su SSO en VPS

Desplegar en un VPS Cloud →

Tutorial

Authentik, Authelia o Keycloak: elegir su SSO en VPS

Seguridad y monitorización6 min de lectura10 pasos

Authelia, Authentik y Keycloak aparecen sistemáticamente en cuanto se busca un SSO autoalojado. Sin embargo, sus alcances difieren radicalmente, y elegir la herramienta equivocada le cuesta RAM, tiempo de operación y, potencialmente, seguridad. Dos CVE publicadas en Keycloak 26.7.1 han reavivado las preguntas comparativas. Esta guía responde a una sola: cuál conviene a su contexto VPS.

Contenido· Por qué estas tres herramientas no hacen lo mismo1/12
  1. 01Por qué estas tres herramientas no hacen lo mismo
  2. 02Lo que cambia en la práctica una elección bien informada
  3. 03Requisitos con cifras según la herramienta elegida
  4. 04Authelia vs Authentik: cuándo elegir cada uno
  5. 05Authelia: cuándo elegirlo
  6. 06Desplegar Authelia en un VPS (Docker Compose)
  7. 07Authentik: cuándo elegirlo
  8. 08Desplegar Authentik en un VPS (Docker Compose oficial)
  9. 09Keycloak: por qué rara vez es la opción adecuada en un VPS
  10. 10Si mantiene Keycloak: tres medidas inmediatas
  11. 11Resolución de problemas: errores frecuentes
  12. 12Qué solución para su contexto

Por qué estas tres herramientas no hacen lo mismo

Authelia es un proxy de autenticación (forward auth, OIDC básico), no un IAM completo. No gestiona un directorio, no habla SAML 2.0 de forma nativa y no aprovisiona cuentas. Authentik es un IAM completo: OIDC, SAML 2.0, LDAP, SCIM, proxy. Keycloak es el IAM histórico en JVM: OIDC, SAML 2.0, LDAP, Kerberos, SCIM. La decisión se basa en el número de aplicaciones y en la necesidad de aprovisionamiento, no en el nombre.

Lo que cambia en la práctica una elección bien informada

  • Authelia por debajo de 30 MB de RAM en reposo — cabe en un VPS de 2 vCPU / 2 GB con su base de datos SQLite.
  • Authentik consolida OIDC, SAML, LDAP y SCIM en un único componente — lo que a veces exige Keycloak + un gestor SCIM aparte.
  • Keycloak solo se impone para Kerberos o la federación SAML empresarial compleja — casos que ni Authelia ni Authentik cubren.
  • La superficie de ataque es proporcional al alcance — un proxy ligero expone menos vectores que un IAM completo.
  • Menos componentes que mantener — una sola herramienta bien elegida reduce el número de CVE que vigilar.
  • El dimensionamiento del VPS depende directamente de la elección — Authelia: 2 GB, Authentik: 4 GB, Keycloak: 8 GB como mínimo.

Requisitos con cifras según la herramienta elegida

Authelia arranca por debajo de 30 MB de RAM y funciona en un VPS de 2 vCPU / 2 GB. Authentik moviliza de 420 a 500 MB en reposo para sus cuatro contenedores (server, worker, PostgreSQL 16, Redis): un VPS de 2 vCPU / 4 GB es la base. Keycloak exige como mínimo 1 GB de heap JVM más 300 MB fuera del heap, es decir un piso de 1,3 GB dedicados antes de cualquier carga; la documentación oficial recomienda 500 MB por cada 100 000 sesiones activas: un VPS de menos de 8 GB no es adecuado para producción. Las tres herramientas necesitan: un nombre de dominio resuelto, TLS válido (Let's Encrypt es suficiente), un reverse proxy (Traefik o nginx) y Docker + Compose.

Authelia vs Authentik: cuándo elegir cada uno

Desplace la tabla

CriterioAutheliaAuthentik
RAM al arrancar< 30 MB420–500 MB (4 contenedores)
ProtocolosForward auth + OIDC básicoOIDC, SAML 2.0, LDAP, SCIM, proxy
Aprovisionamiento SCIMNo
VPS recomendado2 vCPU / 2 GB2 vCPU / 4 GB
Interfaz de administraciónYAML + archivosWeb completa
Curva de aprendizajeBajaMedia
Caso de usoProxy 2FA/SSO ligero (2–6 apps)IAM autoalojado completo (> 5 apps, SAML)
CVE recientes agosto 2026Ninguna anunciadaNinguna anunciada

Authelia: cuándo elegirlo

Elija Authelia para proteger de 2 a 6 aplicaciones internas con 2FA o SSO OIDC ligero, cuando la RAM es limitante y no hace falta aprovisionamiento SCIM. Es la solución estándar para Gitea, Grafana, un panel de administración o el monitoreo, detrás de Traefik o nginx, en un VPS compartido con otros servicios. Authelia no conviene si algunas aplicaciones hablan SAML 2.0 y rechazan OIDC, o si es necesaria la sincronización LDAP con creación de cuentas.

Desplegar Authelia en un VPS (Docker Compose)

  1. Crear la estructura de configuración

    mkdir -p ~/authelia/config && cd ~/authelia — cree config/configuration.yml con jwt_secret, default_redirection_url, session, storage (SQLite), authentication_backend (file).

  2. Generar los hashes de contraseña

    docker run --rm authelia/authelia:latest authelia crypto hash generate argon2 --password 'SuContraseña' — pegue el hash en config/users_database.yml bajo users.<login>.password.

  3. Redactar docker-compose.yml

    Declare el servicio Authelia, monte ./config:/config, exponga el puerto 9091 solo en interno (nunca directamente público) y conéctelo a la red compartida con el reverse proxy.

  4. Configurar el reverse proxy

    Con Traefik: middleware forwardAuth hacia http://authelia:9091/api/authz/forward-auth. Con nginx: auth_request /authelia; y bloques location /authelia. El reverse proxy transmite Remote-User, Remote-Groups y Remote-Email.

  5. Iniciar y verificar

    docker compose pull && docker compose up -d && docker compose logs -f authelia — compruebe el estado healthy y haga la prueba desde un navegador en modo de navegación privada.

Authentik: cuándo elegirlo

Elija Authentik para federar más de cinco aplicaciones, algunas de las cuales hablan SAML 2.0 o usan un directorio LDAP, para el aprovisionamiento automático SCIM, o como sustituto autoalojado de Okta/Auth0/Azure AD. Interfaz de administración gráfica completa para gestionar usuarios, grupos y políticas sin tocar YAML. Authentik está disponible como plantilla VPS en el Marketplace de ServOrbit: stack preconfigurado (4 contenedores) y arranque en unos minutos.

Desplegar Authentik en un VPS (Docker Compose oficial)

  1. Descargar el Compose oficial

    wget https://goauthentik.io/docker-compose.yml — Authentik mantiene un archivo Compose con los 4 servicios: server, worker, postgresql, redis.

  2. Generar los secretos y rellenar .env

    echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env && echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env && echo "AUTHENTIK_ERROR_REPORTING__ENABLED=false" >> .env
  3. Iniciar el stack

    docker compose pull && docker compose up -d — el primer arranque tarda de 1 a 2 minutos (migraciones de PostgreSQL).

  4. Inicializar mediante el asistente

    Acceda a https://authentik.sudominio.com/if/flow/initial-setup/ (puerto 9443 si aún no hay reverse proxy). Cree la cuenta akadmin. Este asistente solo es accesible una vez.

  5. Configurar su primer proveedor OIDC

    Interfaz → Applications → Providers → Create → OAuth2/OIDC. Defina el nombre y el Authorized redirect URI, y anote el Client ID y el Client Secret. Vincule el proveedor a una aplicación y asigne un grupo de acceso.

Keycloak: por qué rara vez es la opción adecuada en un VPS

Keycloak está probado en entornos bancarios y empresariales: Kerberos, federación SAML compleja, alta disponibilidad multinodo. Esas capacidades tienen un costo directo. CVE-2026-15572 (CVSS 8.8) permite a un atacante con derechos de registro de clientes escalar privilegios hasta la administración completa del realm mediante un type-swap de mapper durante una actualización — corregido en Keycloak 26.7.1. CVE-2026-4629 (CVSS 8.1) explota un role mapper con roles endurecidos en clientes gestionados por manage-clients, dando acceso a privilegios no autorizados. En un VPS de menos de 8 GB, la sobrecarga de la JVM consume los recursos disponibles antes de cualquier carga. Keycloak solo es pertinente si tiene una necesidad real de Kerberos o una federación SAML empresarial que ni Authelia ni Authentik cubren.

Si mantiene Keycloak: tres medidas inmediatas

Desactive el Dynamic Client Registration si no lo usa (vector de la CVE-2026-15572). Restrinja /admin a una red interna o a un bastión: ningún acceso de administración directo en la interfaz pública. Configure los Admin Events para redirigirlos a syslog o a una herramienta de monitoreo.

Resolución de problemas: errores frecuentes

Authelia — 404 en /api/authz/forward-auth: desde la versión 4.38, la ruta canónica es /api/authz/forward-auth (antes /api/verify). Actualice la configuración del reverse proxy.

Authelia — bucle de redirección infinito: el session.domain no coincide con el dominio raíz. Debe ser sudominio.com, no auth.sudominio.com.

Authentik — worker en crash loop: OOM killer en un VPS de 2 GB con otros servicios. Las tareas en segundo plano (correos, SCIM) se detienen en silencio mientras la página de login sigue funcionando. Añada RAM o migre los demás servicios.

Authentik — 502 Bad Gateway tras el arranque: las migraciones de PostgreSQL aún no han terminado. Espere de 1 a 2 minutos y compruebe con docker compose logs server que las migraciones están marcadas como OK.

Keycloak — OutOfMemoryError: ajuste KC_JVM_HEAP_MIN y KC_JVM_HEAP_MAX; la regla oficial es asignar el 70 % de la RAM disponible al heap.

Qué solución para su contexto

Authelia para 2-6 aplicaciones internas con 2FA/OIDC ligero (2 GB de RAM, YAML, superficie de ataque mínima); Authentik para más de 5 aplicaciones, SAML 2.0, SCIM, sustitución de Okta/Auth0 (4 GB de RAM, interfaz gráfica); Keycloak únicamente para Kerberos o SAML empresarial complejo (8+ GB de RAM). Authentik está disponible como plantilla VPS en el Marketplace de ServOrbit.

Desplegar Authentik en su VPS

Authentik está disponible como plantilla VPS en el Marketplace de ServOrbit. El entorno está preconstruido y los contenedores vienen preconfigurados: su plataforma IAM queda operativa en unos minutos.

¿Necesita ayuda?

Consulte nuestro centro de ayuda y nuestra FAQ, o contacte con nuestro equipo: llamada, WhatsApp o correo electrónico. Soporte en francés, inglés y árabe.

Escribir por WhatsAppse abre en una pestaña nueva