Cross-Service Authentication in AWS Microservices

This guide explores how to securely manage identity and access when multiple microservices communicate within an AWS ecosystem, focusing on token propagation, IAM roles, and Amazon Cognito.

Learning Objectives

Differentiate between user-to-service and service-to-service (machine-to-machine) authentication.
Implement bearer token propagation using JSON Web Tokens (JWT).
Configure IAM roles for cross-service calls using AWS Signature Version 4 (SigV4).
Apply Amazon Cognito User Pools and Identity Pools to microservice architectures.

Key Terms & Glossary

Bearer Token: A security token (usually a JWT) that grants access to the holder ("bearer") without requiring further credentials.
- Example: An API Gateway receiving a 'Header: Authorization: Bearer ' to validate a user.
JWT (JSON Web Token): An open standard (RFC 7519) for representing claims securely between two parties.
- Example: A token containing the user's ID and permissions signed by Cognito.
OIDC (OpenID Connect): An identity layer on top of the OAuth 2.0 protocol.
STS (Security Token Service): An AWS service that grants temporary, limited-privilege credentials for IAM users or federated users.
- Example: Using AssumeRole to get temporary keys for a Lambda function to access an S3 bucket in another account.

The "Big Idea"

In a monolithic architecture, authentication happens once at the "front door." In Microservices, security must be decentralized. Every service should treat the incoming request as potentially untrusted. The "Big Idea" is Zero Trust: services verify the identity of the caller (whether a user or another service) at every hop using cryptographically signed tokens or AWS-native IAM signatures.

Formula / Concept Box

Mechanism	Best For	Implementation Method
JWT Propagation	User-Identity flow	Pass the Cognito JWT in the `Authorization` header between services.
IAM SigV4	Internal AWS calls	Use SDKs to sign requests with IAM Role credentials (e.g., Lambda calling DynamoDB).
Client Credentials	Machine-to-Machine	OAuth 2.0 flow where Service A gets a token from Cognito to call Service B.

Hierarchical Outline

Identity Providers (IdP)
- Amazon Cognito: Primary managed service for web/mobile identity.
- External IdPs: Social logins (Google, Facebook) via SAML or OIDC.
Authentication Patterns
- Request Headers: Passing tokens in the HTTP Authorization field.
- AWS Signature Version 4: Signing requests for AWS-native services.
Cross-Service Authorization
- API Gateway Authorizers: Lambda-based or Cognito-based filters.
- IAM Policy Scopes: Restricting which services can assume specific roles.

Visual Anchors

Token Propagation Flow

Loading Diagram...

Architecture: API Gateway & IAM

\begin{tikzpicture}[node distance=2cm, every node/.style={fill=white, draw=black, rounded corners, minimum width=2.5cm, minimum height=1cm, align=center}] \node (User) {User}; \node (APIG) [right of=User, xshift=2cm] {API Gateway$Authorizer)}; \node (Lambda) [right of=APIG, xshift=2cm] {Lambda$Service A)}; \node (S3) [right of=Lambda, xshift=2cm] {S3 Bucket$Private)};

code

\draw[->, thick] (User) -- node[above] {HTTPS/JWT} (APIG);
\draw[->, thick] (APIG) -- node[above] {Context} (Lambda);
\draw[->, thick] (Lambda) -- node[above] {IAM SigV4} (S3);

\node[draw=none, fill=none, below of=APIG, yshift=1cm] {\small{Verifies Token}};
\node[draw=none, fill=none, below of=Lambda, yshift=1cm] {\small{Assumes Role}};

\end{tikzpicture}

Definition-Example Pairs

Identity Federation: Linking a user's identity across multiple identity providers.
- Example: Allowing a developer to log into the AWS Console using their corporate Active Directory credentials.
Scope (OAuth2): A mechanism to limit an application's access to a user's account.
- Example: A microservice having a 'read-only' scope so it can view data but not delete it.

Worked Examples

Scenario: Implementing a Lambda Authorizer for Cross-Service Calls

The Problem: Service A needs to call Service B (an API Gateway endpoint). Service B must ensure the call is legitimate.

Step-by-Step Solution:

Token Retrieval: Service A requests a JWT from a Cognito User Pool using the client_credentials flow.
The Request: Service A includes this JWT in the header: Authorization: Bearer <JWT> when calling Service B.
The Authorizer: Service B (API Gateway) triggers a Lambda Authorizer.
Verification: The Authorizer code uses a library (like jose or aws-jwt-verify) to:
- Verify the signature against Cognito's Public Key (JWKS).
- Check the exp (expiration) claim.
- Verify the iss (issuer) matches the expected User Pool.
Policy Generation: The Authorizer returns an IAM policy allowing execute-api:Invoke if the token is valid.

Checkpoint Questions

What is the main difference between a Cognito User Pool and a Cognito Identity Pool?
Why is it preferred to pass a JWT between microservices rather than sharing a database of user credentials?
Which AWS mechanism should be used for machine-to-machine authentication between two Lambda functions where no user is present?
How does a service verify that a JWT was actually issued by your specific Cognito User Pool?

▶Click to see answers

User Pools manage user directories (sign-up/sign-in), while Identity Pools provide temporary AWS credentials to access resources.
Sharing a database creates a single point of failure and a high security risk; JWTs are stateless and can be verified independently by each service.
IAM Roles. Service A should have permissions to invoke Service B, signed with SigV4.
By checking the Issuer (iss) claim in the JWT and validating the signature using the User Pool's Public Key (JWKS).