En el post sobre reverse proxy 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 responde “¿estás en mi red?”; el DNS del 007, “¿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 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 y cloud-first.
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:
- Acceso a la red: Tailscale, WireGuard u OpenVPN
- Resolución de nombres: sslip.io, MagicDNS o Pi-hole
- Terminación TLS y enrutado HTTP: Caddy
- 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 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; 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 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 y por la pila que ya tienes. Los dominios siguen la misma progresión que en el post 008: 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 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) 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.