Categoría: Identidad y acceso
Keycloak: inicio de sesión único (SSO) para vuestra empresa
Un solo inicio de sesión para todas las aplicaciones de vuestra empresa, con doble factor, bajas que cortan el acceso al momento y un servidor de identidad que es vuestro.
- Dónde se monta
- En vuestra cuenta, a vuestro nombre
- Copias
- Con restauración probada
- Actualizaciones
- Planificadas y documentadas
En resumen
Keycloak es un servidor de identidad de código abierto, con licencia Apache 2.0, que ofrece inicio de sesión único (SSO) por OpenID Connect y SAML. Lo instalamos en vuestra cuenta, organizamos los realms y las aplicaciones, activamos el doble factor, lo federamos con vuestro LDAP, Active Directory, Google o Microsoft, lo montamos en alta disponibilidad y nos ocupamos de las actualizaciones y las copias.
¿Qué nos encargamos de mantener?
Keycloak se convierte en la puerta de entrada a todo lo demás: si va lento, todo va lento; si se cae, no entra nadie. Por eso lo tratamos como la pieza más crítica de la plataforma.
Realms y clientes
Cada aplicación conectada con su protocolo, sus roles y sus direcciones de retorno permitidas.
Doble factor
Códigos de un solo uso, llaves de seguridad y passkeys, obligatorios donde haga falta.
Federación
LDAP o Active Directory como origen de usuarios, o Google y Microsoft como proveedores de identidad.
Base de datos
PostgreSQL replicado: guarda la configuración y, en las versiones actuales, también las sesiones.
Clúster
Varios nodos con su caché distribuida, detrás de un balanceador.
Vigilancia
Métricas y registros de inicios de sesión, errores y ataques de fuerza bruta.
¿Qué arquitectura recomendamos?
Para una empresa, un único clúster de Keycloak con al menos dos nodos, repartidos en zonas de disponibilidad distintas si el proveedor las tiene, y una base de datos con replicación síncrona. Los nodos comparten una caché distribuida con Infinispan, integrada en Keycloak, para las sesiones de autenticación. La documentación oficial describe también arquitecturas con varios clústeres en sitios distintos; solo las proponemos cuando la caída de un centro de datos entero no es aceptable, porque doblan la carga de la base de datos.
| Realm | Para quién | Inicio de sesión |
|---|---|---|
| Empleados | Plantilla y colaboradores | Federado con Active Directory, Google o Microsoft, con doble factor obligatorio |
| Clientes | Usuarios de vuestro producto o portal | Registro propio, inicio de sesión social opcional y política de contraseñas |
| Administración | Quien gestiona Keycloak | Muy pocas cuentas, doble factor con llave de seguridad |
¿Qué problemas encontramos al autoalojar Keycloak?
- Consola de administración abierta a internet: el realm maestro accesible desde cualquier sitio.
- Un solo nodo: cada reinicio por actualización deja a toda la empresa sin poder entrar.
- Configuración hecha a mano: nadie sabe qué cliente se creó para qué, ni puede recrearlo.
- Direcciones de retorno con comodines: un cliente acepta redirecciones a cualquier dominio.
- Versiones muy antiguas: instalaciones anteriores al cambio a Quarkus que ya no reciben parches.
- Base de datos sin copia: la configuración de todos los realms vive en una sola máquina.
¿Cómo protegemos, copiamos y actualizamos Keycloak?
Copiamos la base de datos de Keycloak fuera del proveedor y exportamos la configuración de los realms a vuestro repositorio, para poder recrearlos aunque la base de datos no esté. Restauramos periódicamente en un entorno de prueba y comprobamos que se puede iniciar sesión en una aplicación de prueba.
Keycloak saca versiones con frecuencia y, desde que se basa en Quarkus, cada actualización migra el esquema de la base de datos al arrancar. Antes de actualizar leemos la guía de actualización de la versión, hacemos copia, probamos en un entorno aparte con la configuración real y después actualizamos nodo a nodo cuando la versión lo admite; si no, con una parada corta en una ventana avisada. Restringimos la consola de administración a redes concretas, activamos la protección contra fuerza bruta y vigilamos los inicios de sesión fallidos desde la monitorización con Grafana y Prometheus.
¿Qué aplicaciones se pueden conectar?
Cualquiera que hable OpenID Connect o SAML: GitLab, Gitea, Grafana, Argo CD, SonarQube, vuestras aplicaciones propias y muchos servicios en la nube. Para las que no lo admiten, un proxy de autenticación delante hace el mismo papel. La licencia de Keycloak es Apache 2.0: no hay coste por usuario ni licencia que comprar.
¿Keycloak o Authentik?
Los dos dan inicio de sesión único con OpenID Connect y SAML y doble factor, y los dos se montan en vuestra cuenta. Las diferencias reales son estas:
- Keycloak (Apache 2.0, proyecto de la CNCF): más maduro con muchos usuarios y en identidad de clientes, con alta disponibilidad bien documentada y soporte comercial disponible si lo necesitáis. Su consola es más árida y la configuración, más extensa.
- Authentik (núcleo con licencia MIT y una parte Enterprise de pago): consola más amable, flujos de inicio de sesión que se dibujan y un proxy integrado para proteger aplicaciones internas que no saben de SSO, además de servir LDAP a las que solo hablan eso.
Nuestra recomendación: para una empresa con muchas herramientas internas y un equipo pequeño que la va a administrar, Authentik suele encajar mejor. Si la identidad es crítica, hay miles de usuarios o clientes que inician sesión en vuestro producto, Keycloak. Gestionamos cualquiera de los dos con el mismo cuidado: copias de la base de datos, actualizaciones probadas y la consola de administración cerrada.
¿Dónde lo montamos?
En vuestra cuenta, en el proveedor que ya uséis o en el que mejor encaje. Si los datos tienen que quedarse en la UE, Hetzner y OVHcloud son las opciones europeas.
Proveedores en los que lo montamos
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Servidor propio
| Proveedor | Cómo lo montamos | A tener en cuenta |
|---|---|---|
| Hetzner | Varios nodos de Keycloak en servidores cloud o en Kubernetes, con PostgreSQL replicado gestionado por nosotros, porque Hetzner no tiene base de datos gestionada. | El balanceador de Hetzner reparte entre nodos; la base de datos es la pieza que más cuidamos. |
| AWS | Keycloak en ECS o EKS, con RDS o Aurora PostgreSQL detrás de un balanceador de aplicación. | Base de datos en varias zonas de disponibilidad. |
| Google Cloud | Keycloak en GKE o Compute Engine, con Cloud SQL para PostgreSQL en alta disponibilidad. | Encaja si el inicio de sesión de los empleados ya va con Google. |
| Azure | Keycloak en AKS o máquinas virtuales, con Azure Database for PostgreSQL. | Se federa con Microsoft Entra ID para que los empleados entren con su cuenta. |
| DigitalOcean | Keycloak en Droplets o en DOKS, con PostgreSQL gestionado de DigitalOcean. | |
| OVH | Keycloak en Public Cloud o Managed Kubernetes, con base de datos gestionada de OVHcloud. | |
| Servidor propio | Keycloak y PostgreSQL en vuestros servidores, junto a vuestro Active Directory. | Si Keycloak cae, no entra nadie a nada: aquí la alta disponibilidad importa más que en ninguna otra aplicación. |
Qué incluye
- Keycloak en vuestra cuenta cloud o en vuestro servidor, con la configuración de realms y clientes en código.
- Realms separados por uso, por ejemplo empleados y clientes, con sus propias políticas.
- Doble factor con aplicación de códigos o llaves de seguridad y passkeys (WebAuthn).
- Federación con LDAP o Active Directory, o inicio de sesión con Google o Microsoft.
- Conexión de vuestras aplicaciones por OpenID Connect o SAML, con roles y grupos.
- Alta disponibilidad con varios nodos y base de datos replicada.
- Copias de la base de datos y exportación de la configuración de los realms, con restauración de prueba.
- Actualizaciones siguiendo la guía oficial, con prueba previa en un entorno aparte.
Preguntas frecuentes
¿Keycloak es una buena alternativa open source a Auth0 u Okta?
Para la mayoría de usos de empresa, sí: SSO, doble factor, federación y gestión de roles. La diferencia es que tenéis que operarlo vosotros, o alguien por vosotros. A cambio, no pagáis por usuario activo y los datos de identidad se quedan en vuestra cuenta.
¿Cómo se migra de Auth0 a Keycloak sin que la gente tenga que cambiar la contraseña?
Hay dos caminos. Si Auth0 os entrega los hashes de contraseña, se importan en Keycloak con el algoritmo correspondiente. Si no, se hace una migración progresiva: cada persona se valida contra el sistema antiguo la primera vez que entra y queda creada en Keycloak. Lo que no se migra se resuelve con un restablecimiento de contraseña.
¿Keycloak nos ayuda con NIS2 o con el ENS?
Ayuda con una parte: doble factor, control de acceso por roles, bajas centralizadas y registro de inicios de sesión son medidas que piden los dos. Pero ninguna herramienta cumple la norma por sí sola; también hacen falta procedimientos, inventario y gestión de incidentes.
¿Quién da de alta a los usuarios?
Si Keycloak está federado con vuestro directorio, las altas y bajas se hacen allí y Keycloak las aplica. Si no, la persona administradora de vuestra empresa las gestiona desde la consola. Nosotros mantenemos el servidor y la configuración.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Documentación oficial consultada
Los datos técnicos de esta página se basan en:
Revisado el