The Token Gets Checked Before the Lambda Ever Runs

Once the OTP challenge from the last post succeeds, the user is sitting in the Cognito user pool with a set of tokens. The next screen asks for first name, last name, and address, and clicking next has to get that data safely into a database.

That click calls another endpoint behind CloudFront, /user-register, backed by its own API Gateway route. The interesting part isn't the database write itself. It's everything API Gateway does before that write is allowed to happen.

API Gateway checks the token, not the Lambda

API Gateway routes can be wired directly to a Cognito user pool as their authorizer. Every request to /user-register carries the ID token issued back in the OTP flow, and API Gateway checks that token against the user pool before the request goes anywhere else.

• If the token is missing, expired, or doesn't belong to a real user in the pool, API Gateway rejects the request with a 401, and the register Lambda never runs at all.
• If the token checks out, API Gateway forwards the request, along with the user's identity, to the User Register Lambda.

ExpandAPI Gateway checks the token against the Cognito user pool before the register Lambda ever executes

This means the Lambda function never has to verify who's calling it. By the time its code runs, API Gateway has already done that work. The function can trust its input's identity and spend its logic on the actual job: taking the name and address and saving them.

What the Lambda actually does

The User Register Lambda's job here is small on purpose. It receives the first name, last name, and address from the request, and writes that record straight into a DynamoDB user table.

No queue, no retry logic, no background processing. This step runs synchronously: the Lambda writes the row, gets a success response from DynamoDB, and returns success back through API Gateway. The frontend then moves the user on to the vehicle registration page.

That's a different choice than the asynchronous QR code delivery from two posts back, and it's worth noticing why. A single, fast database write doesn't have the same failure risk as a slow external verification call or an SMS gateway. Making everything asynchronous by default would add complexity this particular step doesn't need.

Why the authorization step matters more than it looks

It would be possible to skip the authorizer and just check the user's identity inside the Lambda function itself. Plenty of systems do exactly that.

The problem is that every Lambda function which skips this ends up reimplementing the same token validation logic, and every one of those reimplementations is a place a mistake can slip in. Attaching the check at API Gateway means it's enforced once, in one place, for every route that needs it, and it's enforced before any application code, and any request to the database, ever runs.

That's the same idea from the very first post in this series: push complexity into the architecture where it can be seen and reused, instead of burying it inside every function that happens to need it.

With registration and personal details stored, the next post pulls back to look at the whole user registration design so far, and checks it against the scalability, cost, security, and complexity bar it was supposed to meet.

The Essentials

1. API Gateway can authorize directly against a Cognito user pool, no custom authorizer Lambda needed for a straightforward token check.
2. A rejected token never reaches the Lambda function. The 401 happens at the gateway, before any application code runs.
3. The Lambda can trust its caller's identity, since API Gateway already verified it upstream.
4. Not every step needs to be asynchronous. A single fast database write is a fine candidate for a synchronous call, unlike a slow external verification or an SMS send.
5. Centralizing the auth check avoids reimplementing it in every function. One enforced rule beats the same logic copied into five Lambdas.

Further Reading and Watching

• Video: AWS re:Invent 2023 - Advanced serverless workflow patterns and best practices (API401)
• Docs: Controlling access to a REST API with Amazon Cognito user pools (AWS docs)