WordPress identity decision
Amazon Cognito vs WordPress-Native Authentication
The real choice is not which login form looks better. It is whether visitor identity belongs to the WordPress application or must remain useful across static pages, federated providers and protected APIs.
Short verdict Use WordPress-native authentication when WordPress itself is the application boundary. Use Cognito with Gatey when application identity must survive static publishing, federate social or SAML/OIDC providers, or authorize APIs beyond WordPress.
The decision
Choose where identity remains authoritative
Login, account state and API authorization become harder to reason about when they are spread across several systems without a deliberate identity boundary.
Runtime
WordPress sessions depend on WordPress serving the request
That is natural for dynamic WordPress, but it does not fit a public frontend that is statically delivered and no longer calls PHP for page views.
Federation
External identity providers create a wider application boundary
Social providers and custom SAML/OIDC federation are easier to treat as application identity when Cognito is the hub rather than adding separate login logic per site surface.
Authorization
A website session is not the same as API authorization
Protected APIs need tokens, IAM or another backend-enforced mechanism that can be validated independently of visible WordPress roles or buttons.
Decision implication Keep WordPress-native users when the application boundary is WordPress. Move visitor identity to Cognito when the same identity must cross frontend, API or federation boundaries.
Side-by-side
Compare the identity operating model
Both models are valid. The stronger fit depends on where authentication state must remain useful after login.
| Decision criterion | Amazon Cognito + Gatey | WordPress-native authentication |
|---|---|---|
| Frontend runtime | Gatey authenticates in the browser against Cognito, so supported login, registration, MFA, password reset and profile flows can continue after static export. | Native users and sessions fit a live WordPress runtime where PHP and the WordPress database remain available for authenticated requests. |
| Federation and APIs | Cognito can federate social and custom SAML/OIDC providers. Gatey can use resulting identity for JWT- or IAM-authorized API access. | WordPress plugins can add SSO and API patterns, but the native user/session model remains centered on WordPress unless additional architecture is introduced. |
| Operational fit | Best when identity is an application service shared by static pages, APIs or multiple surfaces, and the team accepts operating Cognito. | Best when WordPress itself is the application and existing plugins rely on native users, roles and sessions. |
Which identity model fits the project?
Choose Cognito + Gatey
When identity extends beyond WordPress
- The public frontend may be static while visitors still need login, registration, MFA or profile flows.
- The same users must access protected APIs or federate through social, SAML or OIDC providers.
- WordPress should remain the CMS and presentation layer rather than the application identity database.
Choose WordPress-native auth
When WordPress is already the right identity boundary
- The site remains a conventional dynamic WordPress application.
- Membership or plugin behavior depends directly on WordPress user IDs, roles and sessions.
- There is no need for a separate identity service, static frontend login or cross-application API identity.
Problem guides
Continue from the identity problem
When should Cognito become the application identity layer?
Start with Use Amazon Cognito Instead of WordPress as the Application Identity Layer, then use Cognito Day-2 Identity Architecture for WordPress for the implementation boundary.
How do I add login to static WordPress without PHP sessions?
See Add Login to Static WordPress Without Bringing PHP Sessions Back. Gatey performs supported authentication flows in the browser against Cognito, so the public page does not need a WordPress session.
How do I connect existing SAML or OIDC identity providers?
Use Connect WordPress to Existing SAML and OIDC Identity Providers Without Building Separate Login Flows. Custom SAML/OIDC providers are a Gatey Pro capability configured through Cognito.
Does a successful login automatically authorize APIs or protected files?
No. Protected APIs must validate JWT, IAM or another appropriate backend authorization mechanism. Protected static paths have a separate CloudFront access boundary.
Choose the identity boundary first
Use Cognito when identity must remain useful outside the WordPress session
Start with the application-identity problem, or use the static-login guide when removing PHP sessions from the public frontend is the immediate requirement.