El equipo expone Grafana en tres clics "temporalmente" para su auditoría. Sin SSO nativo, la contraseña de administrador predeterminada se cambió "más tarde". Dos semanas después, el puerto 443 todavía apunta a Internet con una autenticación básica casera fácil de usar por fuerza bruta.
Un proxy OAuth (oauth2-proxy, OAuth2 Proxy, Vouch, etc.) coloca la autenticación donde la aplicación heredada no puede hacerlo: al frente, no adentro.
Arquitectura típica
Cliente → terminador TLS (nginx/Traefik) → oauth2-proxy → aplicación ascendente. Flujo: redirección de IdP (Google Workspace, Azure AD, Keycloak) → devolución de llamada → cookie cifrada → acceso a la aplicación.
La aplicación permanece en HTTP interno; sólo el borde está expuesto.
Configuración segura
Cookie: segura, HttpOnly, SameSite=mínimo Lax. giratorio --cookie-secret. Restrinja --email-domain o grupos OIDC.
Nunca exponga el flujo ascendente directo sin autenticación paralela: omisión inmediata.
Encabezados y confianza
Pase X-Usuario reenviado/Correo electrónico/Grupos. La aplicación no debería creer en estos encabezados del mundo; firewall o política de red: sólo desde el proxy.
Para la aplicación RBAC (administrador versus visor), asigne reclamos OIDC → encabezados o use una segunda ruta de proxy por función.
Casos especiales
Webhooks entrantes: ruta de omisión de autenticación con secreto HMAC separado.
API de máquina: no oauth2-proxy: mTLS o token de API dedicado.
Comprobaciones de estado: /health sin autenticación para el balanceador de carga, sin datos confidenciales.
Operación
Registros centralizados de errores de autenticación. Caducidad de la sesión alineada con la política de la empresa. Procedimiento de baja de documentos: revocar sesiones de IdP + rotar la cookie secreta si la salida es sensible.
Lista de verificación de implementación
- Aplicación ascendente inaccesible directamente desde Internet
- Cookie Secure HttpOnly SameSite configurado
--email-domaino grupos OIDC restrictivos- Rutas de derivación enumeradas (salud, webhook HMAC)
- Los encabezados X-Forwarded-* confían en el lado de la aplicación solo desde el proxy
- WebSocket probado de un extremo a otro
- La sesión vence de acuerdo con la política de recursos humanos.
- Registros de errores de autenticación centralizados
- Procedimiento de baja documentado
- Renovación del certificado certificado probada sin cierres de sesión masivos
Valide con la prueba interna de “omisión de proxy”; si tiene éxito, corrija la red antes de anunciar el SSO.
Integración del equipo y del ciclo de vida
Incorporación: el nuevo ingeniero recibe acceso IdP + ruta ProxyJump/oauth del documento, no una URL ascendente directa. Eliminación: revocar el IdP e invalidar las cookies de sesión (rotar la cookie secreta si la salida es sensible).
Multientorno: puesta en escena de oauth2-proxy para el registro de la aplicación de preparación de IdP: no comparta client_id prod/staging.
Observabilidad: métrica 401/403 oauth-proxy frente a 502 ascendente: distinga el error de autenticación frente a la aplicación inactiva.
Limitaciones: oauth2-proxy no reemplaza la autorización fina (aplicación RBAC): autentica, la aplicación aún autoriza.
Herramientas múltiples internas (Grafana + Prometheus + Kibana): un proxy oauth2 por Traefik central de autenticación ascendente o de reenvío; ambas funcionan, no mezcle cookies secretas.
Duración de la sesión versus tiempo de espera de inactividad: alinearse con la sensibilidad de los datos (registros de producción versus wiki de recursos humanos).
Cuenta local de rotura de cristales deshabilitada de forma predeterminada, habilitada únicamente mediante el procedimiento de rotura de cristales, sin puerta trasera olvidada.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
SSO de red
Upstream accesible por IP = derivación de SSO. Inicio de sesión <30 segundos documentado.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Decide y avanza sin puntos ciegos
- Corte el acceso directo a Internet a la aplicación ascendente: solo el proxy debe ser accesible públicamente.
- Configurar cookies seguras HttpOnly SameSite: omita las rutas enumeradas (estado, webhooks HMAC firmados).
- Restringir dominios o grupos OIDC: sesión de vencimiento alineada con la política de recursos humanos, registros de autenticación centralizados.
- Pruebe WebSocket de un extremo a otro: encabezados X-Forwarded-* confiables únicamente desde el proxy.
- Pentest bypass proxy: procedimiento de baja documentado, renovación de certificados sin cierre de sesión masivo.
Compare el alojamiento adecuado para pilas SSO a través del directorio y nuestras guías.
Preguntas frecuentes
¿oauth2-proxy frente a proxy inverso clásico?
oauth2-proxy gestiona el flujo OAuth/OIDC y establece una cookie de sesión; nginx por sí solo no valida la identidad del IdP sin un módulo adicional.
¿La aplicación ve al usuario real?
A través de los encabezados X-Forwarded-User/Email/Groups, si están configurados, la aplicación debe confiar en ellos solo desde el proxy (ACL de red).
¿Cómo gestionar WebSockets?
Habilite la compatibilidad con WebSocket ascendente en nginx/traefik; oauth2-proxy debe permitir rutas de actualización con la misma cookie de sesión.
¿Riesgo si está mal configurado?
Omitir una lista blanca de IP demasiado grande, una cookie sin Secure/HttpOnly o una aplicación que acepte encabezados falsificados de Internet.
Antes de anunciar "SSO habilitado", intente llegar al flujo ascendente sin pasar por el proxy; si funciona, no ha terminado.