Sign In

Gatey + Amazon Cognito

Use Amazon Cognito Instead of WordPress as the Application Identity Layer

WordPress can remain the CMS and presentation layer while Amazon Cognito owns frontend application identity, account lifecycle, MFA, federation, and the tokens used by protected APIs.

Short answer Use Gatey to render Cognito-backed authentication inside WordPress. The browser authenticates against your Cognito User Pool, while WordPress keeps responsibility for content and layout instead of becoming the application identity store.

Why separate identity

CMS users and application users do not always belong in the same runtime

WordPress user accounts are useful for editors and simple membership use cases. Application identity becomes a different problem when the same user must authenticate to APIs, static frontends, SSO providers, or other AWS services.

Runtime coupling

WordPress authentication assumes a WordPress session

A PHP session is convenient on a dynamic WordPress site, but it becomes a constraint when the frontend is static or the same identity must work outside WordPress.

Federation

Enterprise and social identity should not require separate WordPress login logic

Cognito can act as the identity hub for native users, social providers, and configured SAML or OIDC providers while Gatey exposes the resulting frontend experience.

APIs

Protected application actions need a portable identity token

Forms, account functions, workflows, and other APIs should authorize the caller independently. Cognito JWT or IAM-based access gives those services an identity boundary that is not tied to WordPress PHP.

Architecture boundary Let WordPress own editorial users and content. Let Cognito own application identity when the identity must extend beyond the CMS runtime.

Identity boundary

WordPress presents the experience; Cognito authenticates the application user

Gatey connects WordPress pages to Cognito directly from the browser, so the same frontend identity model can work on dynamic or statically exported WordPress sites.

WordPress / Gutenberg
      |
      v
Gatey Authenticator and account UI
      |
      v
Visitor browser
      |
      v
Amazon Cognito User Pool
      |  login / registration / MFA / profile
      |  social / SAML / OIDC federation
      v
JWT / identity context
      |
      +--> conditional frontend UI
      +--> API Gateway / protected APIs
      +--> static-site identity flows

Authorization boundary Frontend identity state can improve the user experience, but hiding a block is not authorization. Every protected backend endpoint must validate the token or IAM identity independently.

Implementation

Move application identity without moving the CMS

Configure Cognito as the identity source, then connect it to the WordPress frontend through Gatey.

  1. Create or select the Cognito User Pool — Configure the App Client, login mechanisms, required attributes, MFA, and identity providers needed by the application.
  2. Connect Gatey — Configure the User Pool ID, App Client ID, region, and frontend authentication experience in WordPress.
  3. Design account-aware frontend behavior — Place login, registration, profile, and account-attribute blocks where the experience needs them, and define any conditional frontend presentation.
  4. Protect application APIs separately — Use JWT or IAM authorization for APIs and test the same identity path on the production or statically exported frontend.

When Cognito should own application identity

Good fit

Use Cognito when identity extends beyond WordPress

  • The site needs frontend login, MFA, profiles, or SSO that should keep working after static export.
  • The same users must call protected APIs or participate in AWS-backed application workflows.
  • You want WordPress focused on content and presentation rather than acting as the primary application identity store.

Keep WordPress-native users

WordPress users may be simpler when

  • Only WordPress itself needs authentication and the site remains fully dynamic.
  • There are no external applications, APIs, static frontends, or enterprise federation requirements.
  • The team does not want to configure or operate Amazon Cognito.

Buyer questions

Cognito as the WordPress identity layer FAQ

How can I use Amazon Cognito instead of WordPress users for application authentication?

Use Cognito as the frontend identity provider and Gatey as the WordPress integration layer. The browser authenticates against the configured User Pool and can use the resulting identity for account UI and protected API calls.

Can Cognito login work after WordPress is exported statically?

Yes. Gatey runs the authentication flow in the browser against Cognito, so the public frontend does not need a WordPress PHP session to sign users in.

Can Cognito provide MFA and enterprise SSO?

Yes. Cognito can provide MFA and federate configured SAML or OIDC providers. Gatey exposes those frontend flows in WordPress according to the site configuration and plan.

Does using Cognito mean WordPress users disappear?

No. WordPress users can remain for administrators and editors. The architecture separates editorial identity from frontend application identity when those responsibilities need different runtimes.

WP Suite Gatey

Keep WordPress as the CMS and move application identity to Cognito

Use Gatey to connect WordPress pages to Amazon Cognito for frontend authentication, MFA, SSO, and protected API access.

Explore Gatey
View the Cognito architecture