WordPress identity decision
Amazon Cognito vs WordPress-Native Authentication
WordPress already has a mature user system, while Amazon Cognito moves the primary identity boundary outside WordPress. Gatey adds a ready-made WordPress presentation layer for Cognito, including account flows that otherwise require additional frontend implementation.
Short verdict Choose WordPress-native authentication when users primarily need conventional WordPress accounts, roles, and plugin-driven site access. Choose a Cognito-first model with Gatey when identity must keep working on a static frontend, federate external providers, issue tokens for APIs, or provide advanced Cognito account flows without building each screen yourself.
The identity question
Decide what the user account belongs to — and who builds the account experience
The login screen is only the visible part. The deeper decision is where identities, sessions, tokens, federation, and application access should be anchored, and how much custom frontend work the chosen identity model requires.
Runtime
WordPress users assume a WordPress runtime
The native model fits naturally when WordPress PHP remains available for login, sessions, roles, profile behavior, and plugin integrations. A static frontend changes that assumption.
Application access
A website session and an API identity are not always the same thing
Projects that call protected APIs may need JWT claims or temporary AWS credentials that other services can validate without asking WordPress to proxy every request.
Account UX
Cognito capabilities still need a usable frontend
Cognito exposes identity APIs and flows, but advanced account management still needs screens, navigation, state handling, localization, validation, and error handling. Gatey packages these concerns into a WordPress-facing authentication experience.
Decision implication Keep identity native to WordPress when the application boundary is WordPress. Move identity to Cognito when users must remain meaningful beyond the WordPress runtime, and use Gatey when you also want those Cognito capabilities exposed as reusable WordPress account screens rather than project-specific frontend code.
Side-by-side
Compare the identity boundary and the implementation surface
Both approaches can support production sites. The difference is not only where users live, but also how much account UI and application integration must be built around the identity service.
| Decision criterion | Amazon Cognito + Gatey | WordPress-native users |
|---|---|---|
| Primary identity and runtime | Users and authentication flows live in the configured Cognito User Pool; Gatey renders the WordPress-facing experience and can keep working after static export. | Users, roles, authentication state, profile behavior, and plugin integrations are centered on the WordPress application and database. |
| APIs, federation, and static delivery | Cognito can federate social, SAML, and OIDC providers, issue JWTs for APIs, support IAM-oriented access through an Identity Pool, and authenticate from a static frontend. | Natural fit for dynamic WordPress. Static delivery, external federation, or reusable API identity usually requires additional architecture or plugins around the native user/session model. |
| Advanced account UX | Gatey extends the standard Cognito/Amplify UI path with dedicated editAccount, setupTotp, passwordlessSettings, and rememberedDevices screens, plus localized WordPress placement and navigation. | Native WordPress covers its own account model well, but equivalent Cognito-style TOTP enrollment, passwordless configuration, device management, and federated account UX would require separate plugins or custom implementation. |
Choose where identity should remain authoritative
Choose Cognito + Gatey
When identity is part of the wider application
- The public WordPress frontend may be statically exported while login, profile, and account flows must continue in the browser.
- The same authenticated user needs to call protected APIs with JWTs or temporary AWS credentials, or sign in through social, SAML, or OIDC providers.
- The project needs advanced account screens such as editAccount, setupTotp, passwordlessSettings, or rememberedDevices without building the surrounding Cognito frontend flow from scratch.
Choose WordPress-native users
When WordPress itself is the application boundary
- The site remains dynamically served by WordPress and native users already fit the membership or editorial requirement.
- Plugins depend heavily on WordPress user IDs, roles, sessions, and native account lifecycle behavior.
- The team values the simplest conventional WordPress operating model and does not need Cognito-oriented federation, static authentication, API identity, or advanced Cognito account-management screens.
Evaluation questions
What Gatey adds when Cognito becomes the identity layer
What does Gatey add beyond the standard Cognito and Amplify UI experience?
Gatey provides a WordPress-facing Authenticator layer and dedicated account screens including editAccount, setupTotp, passwordlessSettings, and rememberedDevices. These turn lower-level Cognito capabilities into reusable user-facing flows instead of requiring each project to build the surrounding screens, navigation, state handling, localization, validation, and error behavior itself.
Does Gatey replace Amazon Cognito?
No. Cognito remains the identity backend responsible for the configured User Pool, authentication flows, tokens, MFA, devices, and identity providers. Gatey supplies the WordPress presentation and integration layer around those capabilities.
Can Cognito login and these account flows work after WordPress is exported statically?
Gatey's authentication UI runs in the browser against Cognito, so the public frontend does not need WordPress PHP for sign-in and supported client-side account operations. The published site still needs the required Gatey assets and configuration.
When is WordPress-native authentication still the better choice?
When the site is fundamentally a conventional dynamic WordPress application and its plugins, memberships, roles, and account workflows already fit the native user system, adding Cognito and a separate identity architecture may be unnecessary complexity.
Choose the identity boundary deliberately
Use Cognito for a wider identity layer without rebuilding its WordPress account UX from scratch
Explore Gatey when the project needs Cognito identity plus ready-made WordPress account screens, static compatibility, federation, and protected API access. Keep native WordPress users when those additional identity capabilities are not required.