Cognito User Pools Integration with API Gateway & Application Load Balance | Overview.

Cognito User Pools (CUP) Integration with API Gateway & Application Load Balance (ALB) - Overview.

Scope:

• Intro,
• Architecture,
• CUP with API Gateway,
• CUP with Application Load Balancer,
• Use Case,
• Workflow,
• Comparison table of API Gateway vs. ALB integrating with CUP,
• Security Considerations,
• Final thoughts.

Intro: 

• Both API Gateway and Application Load Balancer (ALB) have native integrations with Cognito User Pools (CUP) to handle user authentication.
•  However, they serve slightly different architectural patterns and have distinct configuration methods.

Architecture

1. CUP with API Gateway

• Amazon API Gateway provides a managed way to expose APIs. CUP is then used as an authorizer.

 Workflow

1.     User Authentication

•    User signs in via Cognito User Pool (Hosted UI, SDK, or app).
•    CUP issues JWT tokens (ID, Access, Refresh).

2.     API Gateway Authorizer

•    API Gateway uses the Cognito Authorizer.
•    The client sends the JWT access token in the Authorization header (Bearer <token>).
•    API Gateway validates the token (signature, expiration, audience, scope).

3.     Authorization

•    If valid → request is forwarded to the backend Lambda/ECS service.
•    If invalid/expired → API Gateway rejects the request (401/403).

4.     Fine-Grained Control

•    API Gateway can use Cognito groups/roles/claims for RBAC (role-based access control).
•    Lambda Authorizer can add more logic (custom claims, context injection).

Use Case:

• Secure REST/HTTP APIs with token-based auth (common in microservices, mobile, serverless apps).

2. CUP with Application Load Balancer (ALB)

• ALB supports OIDC authentication natively. Cognito User Pool acts as the OIDC IdP.

 Workflow

1.     User Authentication

•    User requests a web app behind an ALB.
•    ALB redirects user to Cognito User Pool (OIDC Auth).
•    User signs in (password, social, SAML, MFA).
•    Cognito issues OIDC tokens (JWTs).

2.     ALB Validation

•    ALB validates tokens automatically.
•    No need to write custom code for token verification.

3.     Session Handling

•    After validation, ALB sets a secure cookie session.
•    Backend services only see authenticated traffic.
•    ALB can inject user claims into HTTP headers (like x-amzn-oidc-data, x-amzn-oidc-identity).

4.     Authorization

•    Backends can inspect OIDC claims for fine-grained access.
•    ALB offloads all authentication overhead → apps stay stateless.

Use Case:

• Protect web applications (ECS/EKS apps, legacy apps, or EC2 services) without modifying backend code.

3. Comparison table of API Gateway vs. ALB integrating with CUP

Feature	API Gateway + CUP	ALB + CUP
Best for	REST APIs, serverless apps	Web apps, containers, microservices
Auth method	Token-based (JWT via headers)	OIDC, cookie/session-based
Validation	API Gateway authorizer checks tokens	ALB natively validates tokens
Customization	High (Lambda authorizers, claims-based RBAC)	Limited (header injection, session cookie)
Backend	Lambda, DynamoDB, microservices	ECS, EKS, EC2, legacy apps

4. Security Considerations

•         Always enable HTTPS/TLS.
•         Use short-lived access tokens (default 1 hr).
•         Enable MFA and Advanced Security Features in CUP.
•         For sensitive apps:
•    API Gateway → fine-grained IAM policies.
•    ALB → header-based authorization logic at backend.

Final thoughts:

•    API Gateway + CUP = Best for API protection with JWT validation, scopes, claims, and RBAC.
•   ALB + CUP = Best for web app protection with OIDC login, automatic token validation, and session cookies.