Cognito Day‑2 Identity Architecture for WordPress

The real Cognito problem is day‑2 architecture

Creating a Cognito User Pool is easy. Running it as the identity backbone of a WordPress-based platform is where the real work starts.

You need branded email delivery, bot-resistant sign-up, social and enterprise IdP linking, group-to-scope mapping, post-confirmation group assignment, optional IAM credentials, API Gateway authorization and a predictable way to repeat all of it across sites and environments.

That is the purpose of the Cognito day‑2 template: it packages the parts that usually become console checklists, Lambda snippets and tribal knowledge into a repeatable identity subsystem.

System boundary

 WordPress / Gutenberg page
        │
        ▼
 Gatey Authenticator block / shortcode / widget
        │ browser-side auth flow, no WordPress client secret
        ▼
 Amazon Cognito User Pool + App Client
        │
        ├── Pre Sign-Up Lambda
        │      reCAPTCHA validation, trusted domains, IdP linking
        │
        ├── Custom Email Sender Lambda
        │      S3 HTML templates, SES when configured, Cognito fallback
        │
        ├── Pre Token Generation Lambda
        │      Cognito groups → sc.group.<group> access-token scopes
        │
        └── Post Confirmation Lambda
               confirmed users → Registered group

 Optional Cognito Identity Pool
        │
        ├── AuthenticatedRole: minimal identity exchange
        └── RegisteredRole: execute-api permissions for confirmed users

WordPress is not the identity provider in this pattern. It renders the UI and stores non-sensitive configuration such as region, User Pool ID and App Client ID. Cognito owns authentication. Lambda triggers implement the day‑2 behavior. API Gateway and IAM consume the resulting tokens or credentials.

What the template provisions

The sign-up flow

Visitor opens a WordPress page
        │
        ▼
Gatey renders the Cognito sign-up UI
        │
        ├─ browser obtains reCAPTCHA token when enabled
        │
        ▼
Cognito SignUp request
        │
        ▼
Pre Sign-Up Lambda
        ├─ validate reCAPTCHA action and score
        ├─ evaluate trusted domains if configured
        └─ link external IdP identities by email when possible
        │
        ▼
Cognito creates the user and sends confirmation
        │
        ▼
Custom Email Sender Lambda
        ├─ load matching HTML template from S3
        ├─ interpolate attributes and confirmation code/link
        └─ send with SES or allow Cognito fallback
        │
        ▼
User confirms account
        │
        ▼
Post Confirmation Lambda adds user to Registered group

The important design detail is that bot filtering, email branding, account linking and group assignment are not WordPress plugin hooks. They happen inside Cognito and Lambda, where they remain valid whether the WordPress frontend is dynamic, statically exported or served behind CloudFront.

Token and authorization model

A common mistake is to treat login as the end of the identity story. For application features, the important question is what the authenticated user can call after login.

The day‑2 template supports a clean split: a user can be authenticated without automatically receiving every runtime permission. After confirmation, the Post Confirmation trigger places the user into the Registered group. The Pre Token Generation trigger can then add scopes based on group membership, such as sc.group.registered and sc.group.admin.

API Gateway methods can be protected with Cognito authorizers and scopes, while IAM-based patterns can use the Identity Pool role mapping. This keeps authorization at the API edge instead of burying it in WordPress templates or frontend visibility logic.

Why the two-role IAM model matters

The Identity Pool part of the architecture is especially interesting because it separates two ideas that are often collapsed into one: “the user is signed in” and “the user may call protected AWS APIs.”

Custom email is infrastructure, not cosmetics

Cognito’s built-in email experience is acceptable for prototypes, but production portals usually need branded HTML emails, localized copy, custom callback links and a clear sender identity.

The template treats email as deployable infrastructure. Starter templates live in S3, the Lambda interpolates known attributes and verification codes, and SES can be used when the sender identity is verified. When SES is not configured, the design can fall back to Cognito’s built-in transport rather than blocking the whole identity rollout.

Security model

Operational failure modes

When this is a good fit

• You want Cognito login in WordPress without turning WordPress into the authentication backend.
• You need social or enterprise SSO, MFA, role-aware APIs or static-export-compatible login.
• You want sign-up hardening with reCAPTCHA and consistent user linking across external identity providers.
• You need branded, template-based Cognito emails that can be managed as deployment assets.
• You plan to compose protected APIs, AI backend or workflow stacks around the same identity backbone.

When not to use this

Related resources

FAQ