Guía completa de Amazon Cognito: construir una “base práctica de autenticación” con User Pools e Identity Pools | Comparación con GCP Identity Platform y Azure AD B2C (Microsoft Entra External ID)
Introducción: Cognito no es una “función de login”, sino una base de autenticación operable
Amazon Cognito (en adelante, Cognito) es un servicio que ofrece autenticación y autorización de usuarios para aplicaciones web y móviles. El primer punto clave para entender Cognito es que no se trata simplemente de “guardar usuarios y permitirles iniciar sesión”. Más bien, te permite diseñar una base de autenticación que incluye integración con IdP sociales/externos, emisión de tokens (OIDC/OAuth 2.0) e incluso la emisión de permisos para que las aplicaciones accedan de forma segura a recursos de AWS.
En fuentes oficiales se indica explícitamente que User Pools actúa como un IdP de OpenID Connect (OIDC) desde la perspectiva de la aplicación, lo que significa que Cognito proporciona la “base de protocolos estándar” requerida por las plataformas modernas de autenticación.
Por otro lado, la autenticación no es algo que “construyes una vez y ya está”. La carga operativa se acumula día a día: MFA, restablecimientos de contraseña, inicios de sesión anómalos, prevención de toma de cuentas, cómo crecen los costos al aumentar los usuarios, e incluso cómo manejar consultas de soporte “cuando algo falla”. Por eso este artículo explica con cuidado cómo hacer que Cognito sea operable en la práctica—usando User Pools e Identity Pools como núcleo—cubriendo el orden de diseño, dónde hacer trade-offs y qué decidir primero.
Además, situamos Cognito junto a GCP Identity Platform y Azure AD B2C (incluyendo el contexto de Microsoft Entra External ID), que suelen compararse en el espacio CIAM (Customer Identity and Access Management). Fuentes oficiales señalan que GCP Identity Platform ofrece backends/SDKs/librerías UI para autenticación en aplicaciones, y que su precio se basa principalmente en MAU (Monthly Active Users).
En Azure, la documentación oficial indica que Azure AD B2C es una oferta CIAM y que no puede comprarse por nuevos clientes después del 1 de mayo de 2025. A la vez, afirma que los clientes existentes pueden seguir usándolo, y el FAQ indica una política de soporte al menos hasta mayo de 2030.
A quién ayuda este artículo: cuanto más “problemas de autenticación” tenga tu equipo, más se nota el beneficio
Primero, está dirigido a equipos de desarrollo de aplicaciones (backend/frontend). El login y el registro son la entrada al producto, por lo que los requisitos suelen cambiar con frecuencia: quieres añadir login social, exigir verificación de correo, mejorar borrado/recuperación de cuentas o alinear la UI de autenticación con tu marca. Si construyes desde el inicio una estructura que pueda “crecer después” alineada con protocolos estándar, el desarrollo se vuelve mucho menos doloroso. Cognito User Pools actúa como IdP OIDC y ofrece endpoints bien organizados para integrar IdPs externos (SAML/OIDC, etc.).
Luego, es útil para equipos de SRE/operaciones. Los problemas de autenticación tienen un radio de impacto grande, y las consultas de soporte tienden a dispararse cuando algo falla. Por eso es importante diseñar un sistema que pueda aislar de dónde viene un “no puedo iniciar sesión”—atributos de usuario, integración con IdP, tokens, expiración, rate limits, entrega de emails, etc. En el mundo Cognito, componentes como Managed Login/Hosted UI, integración con IdP externos y emisión de credenciales temporales de AWS vía Identity Pools están bien separados, lo que facilita construir un mapa de diagnóstico.
También se recomienda a arquitectos que consideren multi-cloud o migración futura. GCP Identity Platform y Azure AD B2C comparten rasgos—precio centrado en MAU e integración por protocolos estándar (OIDC/OAuth, SAML, etc.)—pero el lock-in suele aparecer con más fuerza en “cómo construyes la UI”, “hábitos operativos” y “cambios en políticas de soporte/venta”. Dado que cambiaron las condiciones de compra de Azure AD B2C, las decisiones de nueva adopción deben diseñarse especialmente asumiendo “restricciones institucionales”.
1. Panorama general de Cognito: entender User Pools e Identity Pools separando sus roles
Cognito se entiende más fácilmente si lo ves como dos pilares principales:
- User Pools: directorio de usuarios + autenticación para la aplicación (IdP OIDC)
- Identity Pools: mecanismo que emite credenciales temporales de AWS para usuarios federados
La documentación oficial indica explícitamente que User Pools funciona como un IdP OIDC desde la perspectiva de la aplicación. En otras palabras, es sencillo adoptar una estructura moderna donde la app valida los tokens ID/access emitidos por el User Pool y luego crea una sesión.
Identity Pools, por su parte, se describe como un “directorio de identidades federadas” que puede generar credenciales temporales de AWS a cambio de tokens. Puede empezar con usuarios invitados (no autenticados) y luego expandir permisos tras el inicio de sesión.
Un consejo práctico: no intentes usarlo todo desde el inicio. Para muchas apps, lo más estable es establecer primero “login y tokens” con User Pools y añadir Identity Pools solo cuando exista un requerimiento de acceso directo a recursos de AWS.
2. User Pools: úsalos como IdP OIDC para tu aplicación
2-1. Qué aporta User Pools: convertir el login en un “protocolo estándar”
User Pools es un directorio de usuarios y se describe oficialmente como actuando como un IdP OIDC para aplicaciones. Esto importa porque permite implementar el login no como un “mecanismo propietario”, sino sobre “protocolos estándar”.
Los endpoints del User Pool (managed login, SAML, OIDC, OAuth 2.0, etc.) están organizados como un contrato de servidor. Se indica claramente que acceder al endpoint de autorización inicia la autenticación, y que el endpoint Authorize redirige a la página de inicio de sesión administrada o al login de un IdP.
Con este “comportamiento documentado explícitamente”, la aplicación puede concentrarse en responsabilidades mínimas: “obtener tokens”, “verificarlos” y “refrescarlos”. El comportamiento fino del login (pantallas/flows) puede delegarse a Cognito tanto como sea posible—o, incluso si construyes tu propio UI, puedes diseñarlo siguiendo flujos estándar.
2-2. Managed Login / Hosted UI: empieza teniendo una “pantalla de login gestionable”
Cognito está organizado para que puedas implementar login siguiendo flujos OIDC/OAuth 2.0 usando Hosted UI/Managed Login, y materiales también explican enfoques como Authorization Code Flow (incluyendo PKCE).
En la práctica, sobre todo al principio, suele importar más “ejecutar la experiencia completa de forma segura” (incluyendo resets y verificación de email) que “diseñar una pantalla de login personalizada y bonita”. Un enfoque por fases falla menos: primero haz que funcione con Managed Login y después personaliza a fondo cuando los requisitos de marca estén claros.
2-3. Integración con IdP externos: expandirse a “SSO corporativo” y “login social” vía OIDC/SAML
La documentación describe procedimientos para añadir OIDC como IdP externo a un User Pool, permitiendo incorporar gradualmente proveedores sociales/externos.
El desafío de diseño es que “UX de la app” y “gobernanza de identidad enterprise” suelen chocar:
- En B2C (consumidores), suele preferirse email/password, social login, passwordless, etc., para reducir abandono.
- En B2B (clientes enterprise), suele preferirse SSO del cliente vía SAML/OIDC y enfatizar control de acceso alineado con offboarding/traslados.
Cognito tiene los bloques de protocolo para soportar ambos. Sin embargo, lo difícil es la política de integración—casos como “el mismo email existe en múltiples IdPs” o “coexisten SSO corporativo y login personal”. Esto requiere reglas operativas antes de la implementación técnica.
3. Identity Pools: acceso seguro a recursos AWS vía “token → credenciales temporales”
Identity Pools se describe como un directorio que puede intercambiar identidades federadas por credenciales AWS, generando credenciales temporales para usuarios estén o no autenticados. También se indica explícitamente que puedes elegir el nivel de permisos asignado mediante roles y políticas de IAM.
Casos típicos donde ayuda:
- Una app móvil quiere acceder directamente a servicios AWS (pero no quieres que guarde claves de larga duración)
- Quieres permitir uso como invitado para ciertas funciones y luego expandir permisos tras el login
- Quieres usar tokens de User Pool o de un IdP externo como “puerta de entrada” y emitir permisos AWS de mínimo privilegio
Un consejo clave: “concede solo lo que realmente necesitas” en los permisos de Identity Pools. El acceso directo a AWS es conveniente, pero permisos demasiado amplios pueden causar daños grandes si se abusan. Como Identity Pools permite ajustar permisos vía roles IAM, el diseño de mínimo privilegio es un requisito básico.
4. Ejemplos prácticos: convertir el diseño de Cognito en “patrones” reutilizables para el equipo
Aquí tienes tres patrones representativos que puedes usar ya en discusiones—piénsalo como patrones de razonamiento más que como código.
Ejemplo A: app web B2C (empezar solo con User Pool)
- Objetivo: estabilizar registro, login y reset de contraseña primero
- Arquitectura: User Pool + Managed Login (Hosted UI) para establecer flujo OIDC/OAuth
- Clave operativa: documentar verificación de email y flujos de reset para consultas de soporte “no puedo iniciar sesión”
Al inicio, se recomienda crear un documento delgado de “especificación de login”, aunque sea mínimo—la guía de soporte tiende a generar incidentes cuando varía según la persona.
Ejemplo B: SaaS B2B (introducir SSO del cliente gradualmente)
- Objetivo: ofrecer SSO (SAML/OIDC) por cliente y alinear gobernanza con offboarding/traslados
- Arquitectura: añadir IdPs externos (OIDC/SAML) al User Pool y unificar entrada vía endpoint Authorize
- Clave operativa: plantillar “ajustes del IdP, mapeo de atributos y pasos de prueba” por cliente
El SSO es más difícil para el “primer cliente”; las plantillas rinden mucho desde el segundo. Si planeas templating temprano, el onboarding futuro se simplifica.
Ejemplo C: móvil/juego (expandir permisos de invitado → autenticado)
- Objetivo: permitir jugar como invitado, pero habilitar guardado/sincronización tras login
- Arquitectura: emitir credenciales AWS temporales a usuarios no autenticados (invitados) vía Identity Pools y luego cambiar a un rol distinto con más permisos tras login
- Clave operativa: definir explícitamente la diferencia entre permisos de invitado y autenticado y auditar para evitar crecimiento excesivo de permisos
5. Cómo pensar precios: Cognito es “facturación por MAU”, y se vuelve más predecible si lo diseñas bien
La página de precios de Cognito indica que User Pools se cobra según MAU (usuarios activos mensuales) y muestra ejemplos de cobro por tramos más allá del nivel gratuito (p. ej., 10.000 MAU). También indica que el envío de emails usa SES y se factura por separado.
Un punto práctico: los costos de autenticación tienden a escalar con el número de usuarios, lo que facilita actualizar estimaciones conforme crece el producto. En cambio, si cambias la especificación de autenticación de forma que “aumente la frecuencia de login” sin cuidado, podría afectar definiciones de MAU. Es más seguro discutir iniciativas de negocio (como forzar re-login) y su impacto de costos en la misma reunión.
Además, como el pricing de Cognito muestra varios niveles (p. ej., Lite), puede ser más fácil decidir después si incorporas temprano en el diseño cuánto nivel de protección de seguridad avanzada necesitarás.
6. Comparación con GCP Identity Platform: la experiencia de implementación se impulsa más fácil con “SDK/librerías”
GCP Identity Platform se describe oficialmente como un conjunto de servicios backend, SDKs y librerías UI que facilitan añadir autenticación a apps y servicios. Es decir, la experiencia de desarrollo fluye naturalmente como: “conectar el sign-in vía SDK y luego gestionar desde la consola”.
En precios, se indica explícitamente que muchos métodos de inicio de sesión se cobran por MAU, y que autenticación telefónica/MFA se cobra por mensaje enviado.
Una forma simple de comparar con Cognito:
- Ambos están centrados en MAU: más fácil estimar costos al escalar
- GCP pone la guía de SDK/librerías al frente: menos ambigüedad al integrar en la app
- AWS integra de forma natural emisión de permisos AWS vía User Pools + Identity Pools: cuanto más necesitas acceso directo a recursos AWS, más natural se siente
Más que uno “sea superior”, el ajuste depende de cuánto tu app toque directamente recursos de AWS/GCP y de cuánto de la superficie de auth quieres construir tú.
7. Comparación con Azure AD B2C (contexto Microsoft Entra External ID): ojo con las condiciones institucionales cambiadas
Azure AD B2C se describe oficialmente como una solución CIAM que permite SSO a apps y APIs usando cuentas sociales/enterprise/locales. Los overview también mencionan escala (muchos usuarios/muchas autenticaciones) y monitoreo de amenazas (password spray, brute force, etc.).
El punto clave, sin embargo, es que la documentación oficial en japonés indica explícitamente: a partir del 1 de mayo de 2025, Azure AD B2C ya no puede ser comprado por nuevos clientes.
Además, el FAQ indica que los clientes existentes pueden seguir usándolo (experiencias como crear nuevos tenants y user flows no cambian) y que la política es mantener soporte al menos hasta mayo de 2030.
Por tanto, comparar con Azure requiere no solo evaluación técnica, sino también:
- ¿Vas a continuar como cliente existente? (las condiciones institucionales difieren)
- Si eres nuevo, debes evaluar incluyendo el posicionamiento de Entra External ID (según FAQs y guías oficiales)
En ese sentido, Cognito (según las fuentes oficiales citadas aquí) no muestra una nota similar de “restricción para nueva adopción”, por lo que puede resultar más fácil avanzar con diseño bajo menor incertidumbre institucional.
8. Checklist para evitar fallos: 7 cosas que decidir en las primeras dos semanas
Por último, aquí van “decisiones” que luego se vuelven importantes, empaquetadas de forma amigable para el equipo. Alinear esto temprano hace menos probable que la autenticación se rompa al crecer.
- Prioridad de métodos de login
- ¿Email/password primero? ¿Social primero? ¿SSO enterprise como premisa?
- Manejo de tokens y sesiones
- Usar Authorization Code + PKCE y definir UX para refresh y expiración
- Cuánto atributo de usuario (perfil) guardar en Cognito
- Mantener Cognito “solo auth” o guardar parte del perfil también (afecta facilidad de migración futura)
- Reglas de integración con IdP externos
- Manejo de mismo email, política de linking, estrategia de separación por tenant/cliente
- Si se requiere acceso a recursos AWS (necesidad de Identity Pools)
- Si es necesario, separar roles no autenticado/autenticado y aplicar mínimo privilegio
- Frecuencia de actualización de estimaciones de costos
- Cuándo actualizar proyecciones de MAU y cómo tratar envío de email como costo separado
- Procedimientos estándar para consultas de soporte
- Flujos de primera respuesta para “no puedo iniciar sesión”, email no recibido, falla de reset, mala configuración de SSO, etc.
Resumen: Cognito permite hacer crecer la autenticación con “protocolos estándar + patrones operativos”
Cognito User Pools funciona como un IdP OIDC desde la perspectiva de la aplicación, y el login administrado junto con endpoints OIDC/OAuth 2.0 están organizados. Esto facilita implementar login según protocolos estándar y expandirse después a IdPs externos y operación.
Identity Pools emite credenciales temporales de AWS para usuarios federados y permite ajustar permisos vía roles IAM, siendo muy útil cuando se requiere acceso directo y seguro a recursos AWS.
GCP Identity Platform facilita incrustar autenticación en apps vía SDKs/librerías, con precios claros centrados en MAU.
Azure AD B2C tiene una estructura CIAM robusta, pero como hay restricciones institucionales (elegibilidad de compra) documentadas explícitamente, las decisiones de adopción deben confirmar prerrequisitos además de la evaluación técnica.
Como primer paso, se recomienda usar User Pools con “Authorization Code Flow + Managed Login” como base y construir patrones operativos incluyendo manejo de consultas de soporte. Luego, añadir Identity Pools solo cuando se requiera acceso directo a recursos AWS. Este enfoque ayuda a que la autenticación pase de “algo aterrador” a una “base operable”.