• TechOps Examples
  • Posts
  • Designing an AWS Serverless Architecture for SaaS User Authentication

Designing an AWS Serverless Architecture for SaaS User Authentication

TechOps Examples

Hey — It's Govardhana MK 👋

Along with a use case deep dive, we identify the remote job opportunities, top news, tools, and articles in the TechOps industry.

IN TODAY'S EDITION

🧠 Use Case
  • Designing an AWS Serverless Architecture for SaaS User Authentication

🚀 Top News

👀 Remote Jobs

📚️ Resources

📢 Reddit Threads

🛠️ TOOL OF THE DAY

kluctl - A unified command-line interface to manage large Kubernetes deployments, integrating tools like Kustomize and Helm.

Centered around "targets," Kluctl facilitates deploying, diffing, and pruning across clusters or environments and provides a Web UI for visualization and control.

🧠 USE CASE

Designing an AWS Serverless Architecture for SaaS User Authentication

Building authentication for a SaaS app means handling sign ups, verifying users, managing permissions, and connecting with marketing tools (all while keeping it scalable, secure, and cost effective).

A serverless approach using AWS services like Cognito, Lambda, DynamoDB, and SES provides an event driven, fully managed authentication flow.

Let's break it down.

Download a high resolution copy of this diagram here for future reference.

Services in Designing the Architecture

  • Amazon Cognito → User authentication and identity management.

  • AWS Lambda → Serverless functions to handle business logic.

  • Amazon DynamoDB → Stores user permissions and associated domains.

  • Amazon SES → Sends transactional emails for account notifications.

  • Third party marketing tools → Mailchimp, HubSpot, Beehiiv, ConvertKit etc.,

ABC’s of Authentication Flow and Logic

A. User Sign Up & Confirmation Process

Step 1: User Registration (AWS Cognito)

  • A user signs up via Cognito User Pool, providing email, password, and any required attributes (e.g., name, company, etc.).

  • Cognito sends a confirmation email (default) or an SMS OTP for account verification.

  • Upon successful verification, Cognito triggers the Post Confirmation Lambda (confirmUser).

Step 2: Post Confirmation Trigger – Processing New Users

Once Cognito confirms the user, AWS invokes the Post Confirmation Lambda (confirmUser), which:

  • Writes user details to DynamoDB (Permissions Table).

  • Associates the user with domains (if applicable).

  • Sends a transactional email via SES, welcoming the user.

  • Syncs the user email to marketing platforms (Mailchimp, HubSpot, etc.), if the user opted in.

B. User Login & Token Generation Process

Step 1: User Logs In

  • The user logs in with their Cognito credentials.

  • Cognito verifies the password, generates a JWT token, and triggers the Pre Token Generation Lambda (generateToken).

Step 2: Pre Token Generation Trigger – Injecting Custom Claims

The generateToken Lambda is responsible for enhancing the JWT token with additional information:

  • Fetches user role & permissions from DynamoDB (Permissions Table).

  • Reads associated domains from DynamoDB (Domains Table).

  • Modifies the JWT token, adding:

    • Custom Claims (role, permissions, domains).

    • This allows applications to make authorization decisions without extra API calls.

Why is this necessary?

Instead of querying DynamoDB on every API request, the token already contains what the app needs, thus improving performance.

C. Handling Authenticated API Requests

Once logged in:

  • The user includes the JWT token in requests to protected APIs.

  • The backend validates the token against Cognito.

  • APIs check custom claims (permissions, roles, domains) embedded in the token to enforce access control.

Architecture decisions are subjective. What works for one team might not work for another. Think it through before committing to any design (including mine here).

You may even like:

Looking to promote your company, product, service, or event to 47,000+ Cloud Native Professionals? Let's work together.