--- title: "Identidad soberana en el homelab: Zitadel y el espectro RPS" description: "Identidad en el homelab con Authelia, Keycloak, Authentik y Zitadel: forward auth, IdP central, social login y cuándo encaja cada uno." date: 2026-08-22 locale: es url: https://escribano.dev/es/blog/009-homelab-identity/ --- En el [post sobre reverse proxy](/blog/008-caddy-reverse-proxy-pihole/) la pila ya tenía acceso, nombres, TLS y enrutamiento HTTP. Pero `https://grafana.lan` sin login es una puerta abierta en la LAN (y a veces fuera de ella si algo falló en el perímetro). La cuarta capa responde "¿quién eres?": identidad de aplicación, OIDC, forward auth. La VPN del [post 006](/blog/006-homelab-vpn-access/) responde "¿estás en mi red?"; el DNS del [007](/blog/007-sslip-io-homelab-dns/), "¿cómo se llama?". Si las mezclas, montas un IdP cuando el problema era llegar al NAS, o abres Grafana a internet cuando bastaba un túnel. Parto del [principio RPS](/blog/002-rps-principle/) y del eje puente/ancla aplicados a identidad en homelab. El caso real es Zitadel (recién empezando, sin fingir años de producción) y el hilo sigue el de [soberanía digital](/blog/005-digital-sovereignty/) y [cloud-first](/blog/004-cloud-first-problem/). ## La pregunta después del proxy Con nombre, certificado y enrutado, la tentación es proteger "ya" todos los paneles. Auth básica en Caddy, un contenedor de Authelia, o de golpe un IdP con organizaciones, proyectos y políticas. Las tres cierran *un* login, y cada una asume un problema distinto. Authelia y OAuth2-Proxy hacen **forward auth**: el proxy pregunta a un servicio si la petición puede pasar. Un portero en el borde, sin directorio central de aplicaciones. Keycloak, Authentik y Zitadel son un **IdP**: las apps hablan OIDC o SAML contigo. Esa diferencia importa más que el nombre del producto. En un homelab personal el orden sigue siendo el de la serie: 1. **Acceso a la red**: [Tailscale, WireGuard u OpenVPN](/blog/006-homelab-vpn-access/) 2. **Resolución de nombres**: [sslip.io](/blog/007-sslip-io-homelab-dns/), MagicDNS o Pi-hole 3. **Terminación TLS y enrutado HTTP**: [Caddy](/blog/008-caddy-reverse-proxy-pihole/) 4. **Identidad de aplicación** ← aquí Saltar a la 4 sin las anteriores es tijeras antes de tiempo: identidad de plataforma para un servicio que aún no tiene nombre estable. ## Dos dimensiones | Dimensión | Pregunta | |-----------|----------| | RPS | ¿Cuánto inviertes en la arquitectura de identidad? | | Puente / ancla | ¿Cuánta opcionalidad conservas para migrar mañana? | Una misma decisión puede ser piedra estratégica y ancla fuerte. Social login como único factor es el ejemplo habitual: cero operación hoy, el factor de identidad no es tuyo mañana. ## Espectro RPS: herramientas self-hosted ### Piedra: proteger servicios, ya Auth básica en Caddy o nginx (`htpasswd`) es la piedra mínima: un fichero, un realm, y el navegador pide usuario y contraseña. Sirve para un panel que solo usas tú. No escala a varias apps con SSO, el 2FA es pobre o inexistente, y el día que compartas el homelab con alguien empiezas a odiar la lista de claves. **Authelia** (y OAuth2-Proxy) suben un peldaño sin convertirte en administrador de un IdP. Forward auth y 2FA delante del proxy. El caso honesto es el homelab personal, pocos usuarios, y servicios que no hablan OIDC de verdad (o que no te importa que no lo hablen). Si Grafana, el NAS y Home Assistant solo necesitan que no entre cualquiera en la LAN, Authelia suele ser suficiente. ### Papel: IdP serio, riesgo controlado **Keycloak** es el papel corporativo: Java, pesado, predecible, referencia de industria. Lo eliges cuando el fallo es caro (varios usuarios, apps que ya esperan OIDC, alguien más depende del login) y aceptas operar un servidor que no es ligero. **Authentik** ocupa el mismo hueco estratégico con otro equilibrio: IdP completo, DX más moderna, stack heterogéneo (Python y servicios auxiliares). Más cómodo de vivir en un homelab o un equipo pequeño que Keycloak; sigue siendo papel. Montas directorio, flujos, y te responsabilizas de que no se caiga. Misma estrategia RPS. Distinto precio en RAM, en curva de aprendizaje y en cuánto te recuerda a un producto enterprise. ### Tijeras: identidad como plataforma **Zitadel** nace como IdP cloud-native: event sourcing, multi-tenant por diseño, escrito en Go. En homelab eso se nota en el footprint (más ligero que Keycloak, más compacto que Authentik) y en el modelo mental: organizaciones, proyectos, aplicaciones, políticas. Grafana queda como un cliente más. Tiene sentido cuando la identidad *es* el núcleo: varias apps OIDC de verdad, un SSO que quieres poseer, o un proyecto (una PWA, un SaaS propio) que va a vivir años con esos tokens. El riesgo es el de siempre con tijeras: overengineering si eres una persona y tres servicios detrás de forward auth. ### Falso papel Montar Keycloak o Authentik cuando Authelia bastaba. Montar Zitadel cuando el problema era un `htpasswd`. Se parece a papel (hay un IdP, hay un panel, hay documentación densa) pero pagas complejidad que el contexto no pide. El mismo patrón que [cloud-first](/blog/004-cloud-first-problem/) en miniatura: la herramienta "seria" por defecto. ## Anclas gestionadas: por profundidad No todo el mundo self-hostea el IdP. El espectro managed es otra escala; mejor no mezclarla con la anterior: ``` Menos profunda ──────────────────────────────► Más profunda Social login BaaS auth Cloud IdP Hyperscaler IAM (Google/GitHub) (Firebase, (Cognito, Auth0, (IAM + stack cloud) Supabase) Clerk) ``` | Capa | RPS típico | Reversibilidad | |------|------------|----------------| | Social login solo | Piedra táctica | Ancla en el proveedor social | | Firebase / Supabase Auth | Piedra (MVP) | Ancla media según el acoplamiento | | Cognito, Auth0, Clerk | Papel (auth sin operarlo) | Ancla fuerte | | IAM del hyperscaler | Papel enterprise | Ancla máxima | Supabase puede ser puente si te quedas en Auth y Postgres estándar; ancla si el producto entero vive ahí. Firebase ancla antes. Cognito y Auth0 te quitan la operación y te venden la salida cara. ## Social login "Entra con Google" y nada más es piedra pragmática: cero operación, los usuarios ya existen. También es ancla: no controlas el factor de identidad. Si Google cierra la API, cambia el consentimiento o te bloquea el proyecto, el login se cae y no hay directorio al que volver. El matiz que me interesa es otro. Un IdP propio (Zitadel, Keycloak, Authentik) con Google como *identity broker*. Las apps hablan OIDC contigo; tú federas con Google. Puente parcial: mañana quitas Google y dejas usuarios locales, o añades otro IdP, sin reescribir cada cliente. El ancla se queda en el broker, no en cada aplicación. ## Mi experiencia con Zitadel Lo digo sin postureo: recién empezando. Primeras impresiones. Monté Zitadel detrás de Tailscale, con MagicDNS para nombres y acceso. El perímetro sigue siendo la tailnet del [post 006](/blog/006-homelab-vpn-access/); el IdP no está abierto a internet. La doble ancla: * **Tailscale** coordina la red: puente operativo, ancla en el plano de control salvo que pases a Headscale. * **Zitadel** guarda usuarios y emite OIDC en una instancia mía: puente si te quedas en estándares abiertos. Ancla consciente. La alternativa que evito es abrir todo a internet y delegar el login en Cognito "porque es lo profesional". La configuración es conceptualmente densa. Organizaciones, proyectos, aplicaciones, URIs de redirección, quién es el issuer. Un `htpasswd` no te prepara para ese mapa. Los agentes IAG en CLI recortan la primera configuración (el compose, el Caddyfile, el error tonto de Postgres) y dejan intacto el modelo mental. El agente te deja un YAML que arranca; entender por qué una app no recibe el claim que esperabas sigue tocando hacerlo tú. En [SDD](/blog/015-spec-driven-development-iag/) hablo de esa misma distancia entre artefacto y criterio. El caso operativo, el agente de verdad contra el homelab, da para otro post. Lo que noté enseguida: Go se nota. Zitadel ocupa menos que Keycloak (Java) y menos que Authentik (Python y acompañantes). En un mini PC que ya corre Pi-hole y Caddy, se agradece. Yo empezaría por la [documentación de Zitadel con Caddy](https://zitadel.com/docs/self-hosting/manage/reverseproxy/caddy) y por la pila que ya tienes. Los dominios siguen la misma progresión que en el [post 008](/blog/008-caddy-reverse-proxy-pihole/): sslip.io con certificado autofirmado para probar, un DynDNS si hace falta, dominio real y Let's Encrypt cuando el nombre merezca quedarse. Pi-hole y las renovaciones ACME ya están cubiertas ahí; el IdP no inventa otra física de red. ## Cuándo usar qué Auth básica o Authelia basta cuando: * Eres tú, o un hogar, y los servicios no hablan OIDC. * El problema es que no entre cualquiera, no federar cinco aplicaciones. * Aún no tienes claro si el homelab se queda. Keycloak o Authentik cuando: * Ya hay varias apps OIDC y el login compartido es el problema real. * Quieres un IdP que mucha gente ha operado antes, con el coste de peso (Keycloak) o de stack (Authentik). Zitadel cuando: * La identidad es parte del sistema que estás construyendo, no un candado delante de Grafana. * Te importa el footprint y aceptas un modelo más de plataforma que de portero. * Puedes vivir con primeras impresiones: la herramienta es joven *en tu stack*, no en el mercado. Quédate en social login o en un BaaS cuando el producto aún es un MVP y el coste de operar un IdP supera al de un ancla que ya nombraste. ## Limitaciones honestas * Un IdP no sustituye el perímetro. Zitadel sin VPN (o con el 443 abierto a internet) es otra superficie, no más soberanía. * OIDC mal configurado es peor que `htpasswd`. Un redirect URI laxo o un cliente público mal entendido abre más de lo que cierra. * Tijeras se siente bien el primer fin de semana. Tres meses después, si solo tienes tres servicios, Authelia te habría dejado más tiempo para el hobby. * Hablo desde el primer montaje, no desde años operando esto en serio. ## Lo que viene después Con esta capa, la pila que empecé en [acceso](/blog/006-homelab-vpn-access/) queda nombrada: red, nombres, TLS, identidad. Cada una responde a una pregunta distinta. Si las mezclas, usas Caddy para autenticar usuarios o Tailscale para sustituir OIDC. El hilo siguiente se aleja del rack: cómo gobiernas lo que escribe el agente ([SDD](/blog/015-spec-driven-development-iag/)) y, más adelante, cómo ese mismo agente te ayuda a operar el homelab sin sustituir el criterio. Zitadel, Keycloak o Authelia solo tienen sentido en tu contexto. La pregunta útil es qué estrategia estás jugando y qué anclas aceptas.