SAA-C03

Deep Dive

Practicar ahora
D1 · Arquitecturas seguras

Amazon Cognito: autenticación de aplicaciones

Cognito resuelve el problema de "cómo autentico usuarios en mi app web o móvil sin gestionar un servidor de identidades propio". Aparece en SAA-C03 en escenarios de aplicaciones B2C, acceso directo a servicios AWS desde móvil, y federación con proveedores externos como Google o Facebook.

Icon-Architecture/48/Arch_Amazon-Cognito_48

Cognito User Pools — directorio de usuarios

Un User Pool es un directorio de usuarios gestionado por AWS. Proporciona registro, login, MFA, recuperación de contraseña y verificación de email/teléfono sin necesidad de construir ni mantener infraestructura de identidad.

Tras una autenticación exitosa, Cognito devuelve tres tokens JWT: ID Token (datos del usuario), Access Token (permisos en el User Pool) y Refresh Token (renovar los anteriores).

Federación con IdPs externos

Un User Pool puede actuar como broker de identidad: Google, Facebook, Apple, cualquier proveedor SAML o OIDC. El usuario inicia sesión con su cuenta social y Cognito devuelve un JWT normalizado.

Lambda Triggers

Hooks ejecutados en puntos del ciclo de vida del usuario: pre-signup (validar dominio de email), post-confirmation (crear perfil en DynamoDB), pre-token-generation (añadir claims custom al JWT).

Integración con ALB

Un Application Load Balancer puede autenticar usuarios directamente usando Cognito User Pool como IdP. El ALB valida el JWT y solo reenvía tráfico autenticado al target group — sin código en la app.

Integración con API Gateway

API Gateway soporta un Cognito Authorizer nativo: valida el JWT del User Pool automáticamente en cada request, sin necesidad de implementar una Lambda Authorizer custom.

Trampa de examen

Un User Pool autentica usuarios de la app y devuelve JWT — pero esos tokens no dan acceso directo a servicios AWS (S3, DynamoDB, etc.). Para eso se necesita un Identity Pool. User Pool ≠ acceso a AWS.

Icon-Architecture/48/Arch_Amazon-Cognito_48

Cognito Identity Pools — credenciales AWS temporales

Un Identity Pool (Federated Identities) entrega credenciales AWS temporales a usuarios autenticados o incluso a usuarios no autenticados (guest). Internamente llama a STS AssumeRoleWithWebIdentity y devuelve access key, secret key y session token de corta duración.

Fuentes de identidad soportadas

Cognito User Pool (el caso más habitual en el examen)

Google, Facebook, Apple, Amazon — login social directo sin User Pool

SAML 2.0 / OpenID Connect — proveedores corporativos

Usuarios no autenticados (guest) — reciben credenciales con un IAM Role de acceso limitado

No es lo mismo que IAM Identity Center — Identity Pool es para usuarios externos de tu app, no para empleados de la empresa

Usuario autenticado → IAM Role con acceso completo

El Identity Pool mapea al usuario autenticado a un IAM Role con los permisos necesarios (ej: s3:PutObject en su carpeta de S3).

Usuario no autenticado (guest) → IAM Role con acceso limitado

El Identity Pool asigna un segundo IAM Role con permisos mínimos. Útil para apps que permiten leer contenido público sin login.

Trampa de examen

Identity Pool ≠ User Pool. El User Pool autentica (quién eres). El Identity Pool autoriza acceso a AWS (qué puedes hacer con los servicios). Son componentes distintos que se usan juntos o por separado.

Icon-Architecture/48/Arch_Amazon-Cognito_48

Flujo típico: User Pool + Identity Pool

La combinación de User Pool + Identity Pool elimina la necesidad de un servidor backend para gestionar credenciales AWS. La app móvil o web puede llamar directamente a S3, DynamoDB o cualquier servicio AWS con credenciales de corta duración.

1

Usuario hace login en el User Pool

La app envía email + contraseña (o inicia OAuth con Google). Cognito User Pool valida las credenciales y devuelve un ID Token JWT.

2

App envía el JWT al Identity Pool

La app llama a la API del Identity Pool presentando el JWT del User Pool como prueba de identidad.

3

Identity Pool valida con User Pool y llama a STS

El Identity Pool verifica la firma del JWT contra el User Pool y llama a AWS STS con AssumeRoleWithWebIdentity.

4

STS devuelve credenciales AWS temporales

STS entrega access key, secret key y session token con una duración configurada (entre 15 minutos y 12 horas). El Identity Pool las reenvía a la app.

5

App usa las credenciales para llamar a servicios AWS

La app puede ahora llamar directamente a S3 PutObject, DynamoDB GetItem, etc. con esas credenciales temporales — sin pasar por ningún servidor intermedio.

Icon-Architecture/48/Arch_Amazon-Cognito_48

Integraciones con otros servicios AWS

ALB + User Pool

El ALB puede autenticar requests directamente contra el User Pool. Redirige al usuario a la página de login de Cognito, valida el JWT en cada request y solo pasa tráfico autenticado al target group — sin código de autenticación en la app.

API Gateway + User Pool

API Gateway tiene un Cognito Authorizer nativo: extrae el JWT del header Authorization, lo valida contra el User Pool y rechaza requests con token inválido o expirado. Más simple que una Lambda Authorizer custom para este caso de uso.

S3 + Identity Pool

Fine-grained access: el IAM Role del Identity Pool puede incluir una condición con la variable ${cognito-identity.amazonaws.com:sub} para que cada usuario solo pueda leer y escribir en su propia "carpeta" dentro del bucket S3.

Icon-Architecture/48/Arch_Amazon-Cognito_48

Cuándo usar cada opción

1

Usuarios externos de tu app (registro/login)

Cognito User Pool

Directorio de usuarios gestionado con registro, login, MFA, recuperación de contraseña y federación social.

2

Acceso directo a servicios AWS desde el cliente (S3, DynamoDB)

Cognito Identity Pool

Entrega credenciales AWS temporales a la app. El cliente llama a los servicios directamente sin pasar por un servidor.

3

App móvil que sube archivos a S3 sin servidor backend

User Pool + Identity Pool

User Pool autentica al usuario. Identity Pool convierte el JWT en credenciales AWS temporales para S3.

4

Federar con Active Directory / SAML corporativo para usuarios de la app

User Pool como IdP externo

El User Pool actúa como broker SAML/OIDC — el usuario inicia sesión con AD y Cognito devuelve un JWT estándar.

5

Acceso multi-cuenta corporativo con SSO para empleados

IAM Identity Center (no Cognito)

IAM Identity Center está diseñado para empleados y acceso a múltiples cuentas AWS. Cognito es para usuarios externos de aplicaciones.

Icon-Architecture/48/Arch_Amazon-Cognito_48

Best practices para el examen

1

User Pool = JWT, Identity Pool = credenciales AWS temporales

Esta distinción fundamental aparece en prácticamente todas las preguntas sobre Cognito. User Pool autentica y devuelve tokens JWT. Identity Pool intercambia esos tokens por credenciales STS para acceder a servicios AWS.

2

Acceso directo a AWS desde móvil siempre implica Identity Pool

Si el escenario describe una app que llama directamente a S3, DynamoDB u otro servicio AWS desde el cliente (sin servidor intermediario), la respuesta necesita un Identity Pool — no solo un User Pool.

3

ALB + Cognito = autenticación sin código en la app

Cuando el escenario pide autenticar usuarios en una app web detrás de un ALB sin modificar el código de la aplicación, la combinación ALB + Cognito User Pool es la respuesta correcta.

4

Un usuario no autenticado puede recibir credenciales limitadas vía Identity Pool (guest access)

Los Identity Pools soportan identidades no autenticadas. El guest IAM Role puede tener permisos mínimos (ej: leer objetos públicos de S3) sin que el usuario haya iniciado sesión.

5

IAM Identity Center es para empleados/cuentas corporativas; Cognito es para usuarios externos de tu app

Fácil de confundir en el examen. IAM Identity Center (SSO) gestiona acceso de empleados a múltiples cuentas AWS. Cognito gestiona usuarios finales de aplicaciones B2C. No son intercambiables.

Diagrama: flujo User Pool + Identity Pool

Visualiza los dos caminos: autenticación con JWT y acceso a AWS con credenciales temporales.

¿Entendiste este tema?

Pon a prueba lo que acabas de aprender

Una empresa está construyendo una app móvil. Los usuarios deben poder registrarse con su email, iniciar sesión, y la app necesita subir fotos directamente a un bucket S3 privado sin pasar por un servidor backend. ¿Qué arquitectura es correcta?