Problema

En entornos internos es frecuente encontrar herramientas auto‑hosteadas, scripts rápidos o dashboards creados por equipos que no incluyen un mecanismo de autenticación robusto. Algunas aplicaciones solo exponen un formulario básico, otras ni siquiera solicitan credenciales. Cuando el número de servicios crece, añadir OIDC o SAML a cada uno se vuelve costoso: hay que modificar código, recompilar contenedores y mantener librerías de autenticación en varios lenguajes. El resultado es una superficie de ataque innecesaria y una experiencia de usuario inconsistente, sobre todo cuando la organización ya dispone de un IdP corporativo (Microsoft Entra ID, Azure AD, etc.) con MFA y políticas de acceso condicional.

Causa

  1. Diseño centrado en la rapidez – Los equipos priorizan la entrega de funcionalidades sobre la seguridad, dejando la capa de autenticación para el futuro.
  2. Falta de estandarización – No existe una política clara que obligue a usar OIDC/SAML en todas las aplicaciones internas. Cada proyecto elige su propio método o lo omite.
  3. Limitaciones de la aplicación – Algunas herramientas están escritas en lenguajes o frameworks que no tienen soporte nativo para flujos de autenticación modernos, o el código fuente no está disponible para modificar.
  4. Entorno distribuido – Cuando los servicios se despliegan detrás de un balanceador o un CDN, la autenticación a nivel de aplicación complica la arquitectura y genera puntos de fallo adicionales.

Solución

Mover la autenticación al nivel del reverse proxy permite centralizar el control sin tocar el código de la aplicación. AWS Application Load Balancer (ALB) incluye un auth action que soporta OIDC. Al combinarlo con Microsoft Entra ID (el IdP de la organización) se consigue:

  • Redirección automática a la página de login de Entra ID.
  • Validación del token JWT en el propio ALB.
  • Inserción de cabeceras (X-Amzn-Oidc-Data, X-Amzn-Oidc-Accesstoken) que la aplicación puede usar para identificar al usuario, si lo necesita.

Pasos generales (reutilizables)

  1. Crear una aplicación OIDC en Entra ID

    • Registrar una App registration → Tipo de cuenta: Single tenant o Multitenant según necesidad.
    • Configurar Redirect URI con la URL del ALB que manejará la respuesta, por ejemplo https://app.example.com/oauth2/idpresponse.
    • Anotar Client ID y Client Secret; serán usados por el ALB.

  2. Definir un Target Group que apunte al backend de la aplicación (por ejemplo, un contenedor Docker o una instancia EC2). No es necesario cambiar la configuración de la aplicación.

  3. Crear un Listener en el ALB

    • Puerto 443 con certificado TLS.
    • Regla de prioridad alta que incluya una action de tipo authenticate-oidc.
    • Parámetros clave: Issuer, AuthorizationEndpoint, TokenEndpoint, UserInfoEndpoint, ClientId, ClientSecret, SessionCookieName.

  4. Añadir una regla de forward que, una vez autenticado, envíe el tráfico al Target Group creado.

  5. Configurar políticas de seguridad en Entra ID (MFA, Conditional Access) según los requisitos de la organización.

  6. Opcional: mapear atributos del token a cabeceras personalizadas si la aplicación necesita saber el nombre de usuario o grupos.

Este flujo funciona para cualquier aplicación HTTP/HTTPS que no requiera interacción directa con el IdP. El ALB actúa como un guardián que solo permite el paso a usuarios con un token válido.

Cuándo aplicar esta solución

  • Aplicaciones sin autenticación o con autenticación estática que no pueden ser modificadas.
  • Entornos internos donde el tráfico ya pasa por un ALB o un NLB y se busca evitar un proxy adicional.
  • Políticas corporativas que exigen MFA y revocación inmediata; el IdP gestiona todo.
  • Escenarios de alta rotación de servicios (CI/CD) donde re‑implementar OIDC en cada despliegue sería costoso.

No aplicar si la aplicación necesita flujos de autorización avanzados (por ejemplo, consentimientos de terceros) que requieren interacción directa con el IdP, o si el tráfico no pasa por un ALB (por ejemplo, servicios exclusivamente internos sin exposición pública).

Código

# 1. Crear target group
aws elbv2 create-target-group \
  --name my-app-tg \
  --protocol HTTP \
  --port 80 \
  --vpc-id vpc-0abcd1234efgh5678

# 2. Crear listener con autenticación OIDC
aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/app/my-alb/50dc6c495c0c9188 \
  --protocol HTTPS \
  --port 443 \
  --certificates CertificateArn=arn:aws:acm:region:123456789012:certificate/abcd1234-ef56-7890-abcd-1234567890ab \
  --default-actions Type=authenticate-oidc,AuthenticateOidcConfig={Issuer=https://login.microsoftonline.com/<tenant-id>/v2.0,AuthorizationEndpoint=https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize,TokenEndpoint=https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token,UserInfoEndpoint=https://graph.microsoft.com/oidc/userinfo,ClientId=YOUR_CLIENT_ID,ClientSecret=YOUR_CLIENT_SECRET,SessionCookieName=ALBAuthSession},Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/my-app-tg/6d0ecf831eec9f09

Reemplaza <tenant-id>, YOUR_CLIENT_ID y YOUR_CLIENT_SECRET con los valores obtenidos en Entra ID. El SessionCookieName controla la duración de la sesión; ajusta según la política de tiempo de inactividad.


## Verificación
1. **Acceso directo**: Intenta abrir la URL del backend (por ejemplo, `http://10.0.1.15:80`) desde una máquina dentro del VPC. Debería devolver *403* o *404* porque el ALB no permite tráfico sin autenticación.  
2. **Acceso vía ALB**: Navega a `https://app.example.com`. Deberías ser redirigido a la página de login de Entra ID. Tras autenticación, serás devuelto a la aplicación y verás su interfaz normal.  
3. **Cabeceras**: Usa `curl -I -H "Host: app.example.com" https://app.example.com` y verifica que aparecen `x-amzn-oidc-data` y `x-amzn-oidc-accesstoken`.  
4. **Revocación**: Desactiva la cuenta del usuario en Entra ID y repite el paso 2; el login debe fallar y el ALB debe negar el acceso.

## Notas adicionales
- **Tiempo de sesión**: El ALB mantiene la sesión en una cookie; si la aplicación necesita un *logout* inmediato, invalida la cookie borrándola en el cliente o cambiando el nombre de la cookie en la configuración del listener.  
- **Limitaciones de encabezados**: Algunas aplicaciones rechazan cabeceras largas. Si el token supera el límite, habilita la opción `EnableOIDCAuthentication` en el listener para que el ALB realice la validación sin pasar el token completo.  
- **Logs y métricas**: Habilita `access_logs` en el ALB y revisa los campos `type=authenticate-oidc` para auditoría. CloudWatch Metrics `RequestCount` y `HTTPCode_ELB_5XX_Count` ayudan a detectar bloqueos inesperados.  
- **Alternativas**: Si no se usa AWS, Cloudflare Access o OAuth2‑Proxy ofrecen funcionalidades similares. La ventaja de ALB es la integración nativa con VPC y la ausencia de componentes adicionales.  
- **Escalado**: El ALB escala automáticamente; sin embargo, el IdP puede imponer límites de solicitudes por segundo. Configura *Retry* y *Backoff* en los clientes que consumen la aplicación para evitar bloqueos temporales.