Sign In

Gatey + static WordPress

Add Login to Static WordPress Without Bringing PHP Sessions Back

Static publishing removes WordPress PHP from public page delivery, but many sites still need sign-in, registration, MFA, profiles, SSO, or protected client experiences. Authentication does not have to move back into WordPress to provide them.

Short answer Use Gatey in the browser with your Amazon Cognito User Pool. Login, registration, MFA, password reset, profile flows, and supported SSO happen directly between the frontend and Cognito, so they can continue after static export without a WordPress PHP session.

Why static login is different

Traditional WordPress authentication assumes WordPress serves the request

A static frontend changes that assumption. The browser receives files from S3 or a CDN, so identity and authorization need their own runtime path.

Session

PHP sessions disappear with the public WordPress runtime

Membership and login flows that depend on WordPress cookies and request-time PHP cannot simply keep working when the public site is exported as static files.

Identity

Hiding UI is not authentication

A static page can conditionally show interface elements in the browser, but real identity still needs a trusted authentication service and protected resources need their own authorization checks.

Integration

Login is only the first step

Static applications may also need MFA, enterprise SSO, profile updates, protected API calls, or access to private static paths. Those responsibilities should be explicit rather than hidden inside a WordPress session.

Architecture choice Treat identity as a separate service. WordPress remains the CMS, the static frontend remains the delivery layer, and Cognito becomes the authentication boundary.

Identity path

Browser-side authentication against your Cognito User Pool

Gatey renders the authentication experience in WordPress and keeps it functional after export because the frontend talks directly to Cognito. WordPress does not proxy the authentication request.

WordPress editor
      |
      v
Gatey block / widget / shortcode
      |
      v
Static export --> S3 / CloudFront
      |
      v
Visitor browser
      |
      +--> Amazon Cognito User Pool
      |      login / signup / MFA / profile / SSO
      |
      +--> protected APIs using JWT or IAM
      |
      +--> optional protected static paths via signed access

Security boundary Authentication proves who the visitor is. API authorization and protected static content remain separate controls and must validate or enforce access independently.

Implementation

Add identity without reintroducing the WordPress runtime

Configure Cognito first, then let Gatey provide the frontend experience that survives static publishing.

  1. Create or select the Cognito User Pool — Configure the User Pool and App Client for the login mechanisms and identity providers the project needs.
  2. Configure Gatey in WordPress — Add the Authenticator block, widget, or shortcode and configure sign-in, sign-up, MFA, profile, language, and provider options as required.
  3. Export and test the static frontend — Publish the page statically and verify that the browser can still reach Cognito and complete authentication flows without WordPress PHP handling the request.
  4. Protect the resources that matter — Use JWT or IAM authorization for APIs and a separate protected-path mechanism, such as the Static Site Guardian pattern, for static files or portal sections that must not be public.

When Cognito-backed static login fits

Good fit

Use it when identity must survive static delivery

  • The public WordPress frontend is static but users still need login, registration, MFA, or profiles.
  • The same identity must authorize APIs or integrate with SAML/OIDC providers.
  • You want Cognito to own application identity while WordPress stays focused on content and presentation.

Keep WordPress-native auth

A normal WordPress login may be simpler when

  • The site remains fully dynamic and only WordPress itself needs authenticated sessions.
  • There are no protected APIs, external applications, or static delivery requirements.
  • The team does not want to operate an AWS Cognito identity layer.

Buyer questions

Static WordPress login FAQ

How do users log in to a static WordPress site?

The browser can authenticate directly against an external identity service. Gatey uses Amazon Cognito for login, registration, MFA, password reset, and profile flows, so the public page does not need WordPress PHP to create the session.

Can Amazon Cognito authenticate users on static WordPress?

Yes. Gatey is designed to work on both dynamic and statically exported WordPress frontends because authentication runs in the browser against the configured Cognito User Pool.

Can I add SAML or OIDC SSO?

Yes. Gatey can expose social providers and custom SAML or OIDC identity providers that are configured through Cognito, depending on the selected plan and setup.

Can authenticated users call protected APIs?

Yes. Gatey supports JWT- or AWS IAM-authorized API access. The backend still needs to validate the caller and enforce the appropriate authorization rules.

WP Suite Gatey

Keep authentication outside the WordPress session layer

Use Gatey for Cognito-backed frontend identity, then add protected API or static-path controls only where the application requires them.

Explore Gatey
See protected static architecture