Static WordPress · Authentication
Static WordPress Authentication Made Simple: Deploy with the AWS SAR Template
A static WordPress frontend removes the PHP runtime from public requests, but it also removes native WordPress login from the delivered site. Protected portals, downloads, and member routes therefore need an identity and edge-access model designed for static delivery.
Important update
This deployment path has been superseded
The AWS Serverless Application Repository (SAR) template described in this article is no longer available. WP Suite now uses Deployment Access, with CloudFormation templates covering the backend infrastructure required by all WP Suite plugins.
Stay tuned: a new guide will walk through the updated Deployment Access workflow and the expanded solution.
The pattern
Authenticate with Cognito, authorize delivery at CloudFront.
Gatey signs the user in
The browser authenticates against an Amazon Cognito User Pool through the Gatey experience embedded in WordPress-generated pages.
A signer issues cookies
A protected API verifies the authenticated user and returns CloudFront signed cookies with a limited path and lifetime.
CloudFront protects content
CloudFront behaviors and a trusted key group enforce access before protected static objects are delivered from S3.
01 · Why
Why does static publishing need a different login architecture?
Once WordPress is exported to static files, there is no PHP session or WordPress database request on the public path. The site can still display interactive JavaScript, but the native WordPress authentication system is no longer present at the edge.
The replacement should protect the content delivery path itself, not merely hide links in the browser. CloudFront signed cookies are suitable when an authenticated user needs access to multiple protected files or routes under the same distribution.
- Do not rely on client-side visibility rules as access control.
- Protect the origin so visitors cannot bypass CloudFront and read S3 objects directly.
- Scope cookie policies to the required domain, route, and lifetime.
This creates a static site that remains cacheable and globally delivered while selected content stays behind an enforceable edge policy.
Static vs Dynamic WordPress
| Feature | Dynamic WP (PHP/MySQL) | Static WP (S3 + CloudFront) |
|---|---|---|
| Speed | Server-rendered, depends on PHP/DB | CDN edge-cached, ultra-fast |
| Security | Core/plugins = larger attack surface | Minimal surface (static files) |
| Scalability | Bound by server resources | Virtually unlimited via CloudFront |
| Authentication | Built-in WP login | SAR + Gatey (signed cookies) |
| Maintenance | Patching, DB backups | File sync + cache invalidation |
02 · Components
What does the Static Site Guardian stack provide?
The deployment pattern combines an S3 origin, CloudFront distribution behavior, a CloudFront public key and key group, and API Gateway plus Lambda endpoints that issue and clear signed cookies after authentication.
Supporting resources can store signing material securely, connect a custom domain and certificate, apply WAF protections, and expose outputs that Gatey or the WordPress configuration can use.
- Private S3 origin and CloudFront delivery.
- Cookie issuer and sign-out endpoints with route-specific authorization.
- Customer-owned keys, logs, domains, and AWS service costs.
The exact resources depend on the selected deployment parameters, but access control remains outside the exported HTML files.
03 · Integration
How does Gatey connect login to the protected static routes?
Gatey handles the Cognito account flow in the browser. After a successful sign-in, the frontend calls the configured cookie-issuer endpoint with the required authenticated context. The response sets signed cookies for the CloudFront domain, after which the visitor can request the protected route normally.
Sign-out must clear both the application session and the CloudFront cookies. Redirect destinations should be explicit so expired or unauthorized requests return the visitor to a useful sign-in path rather than a generic delivery error.
- Keep the Cognito callback, site domain, and cookie domain aligned.
- Test login, direct protected URL access, expiry, and sign-out.
- Avoid cookie scopes that cover unrelated sites or paths.
The user sees a normal account journey while the delivery decision remains enforced by CloudFront.
04 · Operations
What should be tested after deployment?
A successful CloudFormation deployment is only the beginning. Publish the static files to the expected S3 prefix, invalidate the relevant CloudFront paths, and verify that public routes remain accessible while protected routes reject anonymous requests.
Then test multiple users, cookie expiry, browser privacy modes, custom domains, CORS behavior on the signer API, key rotation, logs, alarms, and rollback procedures. Confirm that changing the WordPress page does not accidentally remove the integration settings required by the exported frontend.
- Test anonymous, authenticated, expired, and signed-out states.
- Monitor signer failures and unexpected authorization responses.
- Document how keys and configuration are rotated without downtime.
Static delivery reduces the public WordPress attack surface, but it does not eliminate identity, key, API, and operational responsibilities.
Access-control rule
A static page can be interactive, but the browser must not be the security boundary.
Use browser logic to improve the user experience. Use Cognito, protected APIs, CloudFront policies, and a private origin to decide whether the protected content is actually delivered.
Next step
Plan the protected routes before deploying the stack.
Review Static Publisher and Deployment Access to map how the site is exported, where it is delivered, and which paths require signed-cookie protection.