Architecture · Protected static delivery
Secure Static WordPress with CloudFront Signed Cookies
Use Cognito to prove identity, a signer to issue time-limited CloudFront access, and CloudFront to enforce protected static paths without restoring WordPress PHP sessions.
Visitor → CloudFront protected path ↓ no valid cookie Gatey → Amazon Cognito ↓ accepted identity Signer service → signed cookies ↓ CloudFront → private S3 object
Trust boundaries
Identity, static-file access and API authorization are different controls
A Cognito token proves an identity. A CloudFront signed cookie controls retrieval of selected static objects. Protected APIs still need their own JWT, IAM or service-side authorization. Keeping these artifacts separate avoids turning one credential into a universal permission.
Identity: browser → Cognito → tokens Static access: accepted identity → signer → CloudFront cookie → protected path API action: browser → authorized API → backend validation WordPress remains the CMS and does not enforce visitor access at request time.
Delivery boundary Private S3 objects should remain behind CloudFront. Hiding links, JavaScript gating or a successful login does not by itself protect a static object.
What the secure static stack provisions
The protection layer spans storage, edge delivery, signing, identity and abuse controls. This table shows what each component owns and which security boundary it enforces.
| Resource / capability | Purpose | Security boundary | Design note |
|---|---|---|---|
| S3 origin | Stores exported static WordPress files | Objects should not be public when CloudFront is the delivery boundary | Static Publisher can publish files; the protection stack controls access path. |
| CloudFront distribution | Serves public and protected paths at the edge | Protected behaviors require signed cookies | The protected path list is an architectural parameter, not a theme setting. |
| CloudFront key group / public key | Lets CloudFront validate signed-cookie policy signatures | Only CloudFront sees the public key; the private key stays in the signer side | Key rotation needs a runbook. |
| Signer service | Issues signed cookies after identity checks | Private key in KMS/SSM or equivalent protected storage | Can be API Gateway + Lambda or same-domain edge logic depending on cookie scoping needs. |
| Cognito/Gatey integration | Authenticates the visitor before cookies are issued | Identity tokens remain separate from CloudFront cookies | The login page can be part of the static site. |
| Route/DNS/certificate options | Map the public site and optional API/signer domain | TLS and hostnames define cookie behavior | Domain strategy matters as much as Lambda code. |
| WAF / rate controls | Reduce abuse of public and signer routes | Edge-level filtering before runtime execution | Especially useful when protected paths and signer endpoints are public-facing. |
Signed cookies versus JWTs
These credentials prove different things. The comparison below keeps identity tokens, temporary AWS credentials, CloudFront access cookies and WordPress sessions from being treated as interchangeable authorization artifacts.
| Artifact | Issued by | Validated by | Best used for |
|---|---|---|---|
| Cognito ID/access token | Amazon Cognito after authentication | Frontend code, API Gateway authorizer, backend Lambda | Proving who the user is and what identity-related scopes or claims they have. |
| IAM credentials | Cognito Identity Pool / STS | AWS service authorization | Calling IAM-authorized APIs or services from a browser with temporary scoped credentials. |
| CloudFront signed cookie | A trusted signer that owns the private key | CloudFront at the edge | Allowing or denying retrieval of static objects under selected path patterns. |
| WordPress login cookie | WordPress/PHP runtime | WordPress | Admin or traditional dynamic WordPress sessions, not static edge authorization. |
Path protection model
Path classes should be explicit before deployment. This table distinguishes public pages, protected static objects, account pages, APIs and higher-risk runtime endpoints so each surface receives the correct enforcement model.
| Path class | Example | Enforcement | Common mistake |
|---|---|---|---|
| Public content | /, /about/, /blog/, assets | CloudFront cache and S3 origin access control | Accidentally placing private JSON, uploads or generated files under public prefixes. |
| Protected static content | /members/*, /training/*, /client/* | CloudFront signed cookies on matching behaviors/path patterns | Only hiding links while leaving static objects directly fetchable. |
| Sign-in and account pages | /signin/, /profile/ | Gatey + Cognito browser flow | Treating the login page itself as server-side WordPress state. |
| Protected APIs | /api/* or configured API Gateway domain | Cognito authorizer, JWT scopes or IAM | Assuming a CloudFront cookie proves authorization for API mutations. |
| AI or workflow endpoints | /frontend/prompt, /forms/submit | Endpoint-specific auth, WAF, reCAPTCHA and rate limits | Reusing page-access logic for higher-risk runtime actions. |
Failure modes that matter
The protection model is easiest to operate when common failure states are explicit. This table maps visible symptoms to likely causes and the boundary that should be inspected first.
| Failure mode | Symptom | Likely cause | Fix direction |
|---|---|---|---|
| Protected route loops to sign-in | User logs in but keeps returning to sign-in | Cookie domain/path mismatch, signer not setting all required CloudFront cookies or browser rejecting attributes | Inspect Set-Cookie headers, host-only/domain settings and SameSite/Secure attributes. |
| Protected file is public | Private URL opens in incognito without login | S3 object public, CloudFront behavior not protected or direct origin URL exposed | Lock S3 public access, enforce CloudFront origin access and verify behavior path patterns. |
| 403 after valid login | User receives AccessDenied from CloudFront | Expired cookie, wrong key pair ID, invalid signature or policy path mismatch | Check cookie TTL, key group, signer private key and CloudFront policy resource pattern. |
| Works on one subdomain, fails on another | Cookies are not sent or wrong cookies are sent | Domain cookie vs host-only cookie mismatch or collision across sites | Move toward same-domain issuance or isolate environments with distinct hosts and keys. |
| API succeeds without page access or vice versa | User can call API but not view static page, or view page but cannot call API | Separate auth layers configured differently | Treat static access and API authorization as separate policies and document both. |
Implementation path
Design protected paths before publishing them
The protected-content model should be explicit before the static artifact reaches production.
- Define public and protected path classes — Identify which URLs and assets remain public and which path patterns require authenticated signed-cookie access.
- Configure Cognito-backed identity — Use Gatey and the configured Cognito User Pool for browser login, MFA, profile or SSO requirements without making WordPress the frontend session authority.
- Deploy the signer and CloudFront policy — Keep signing key material on the trusted signer side, scope cookie policies to the required paths and use cookie TTLs appropriate to the protected content.
- Test access as a delivery problem — Verify anonymous denial, post-login access, expiry, direct S3 access, cookie-domain behavior and API authorization separately.
When signed-cookie protection fits
Good fit
Shared static content with authenticated access
- A static WordPress site has member, client, documentation, training or portal paths that can be represented as shared static objects.
- You want public pages and protected pages delivered by CloudFront rather than reintroducing PHP sessions.
- Cognito already owns visitor identity or is the intended application identity boundary.
Choose another pattern
Use a different authorization model when
- The page itself must be rendered differently for each user on the server.
- Access must be revoked immediately per request and cannot rely on an appropriately short signed-cookie lifetime.
- The site remains fully dynamic and ordinary WordPress role/session protection already meets the requirement.
Problem guides
Buyer problems this architecture supports
How do I add login to static WordPress without PHP sessions?
Use Add Login to Static WordPress Without Bringing PHP Sessions Back as the pain-first entry point. It explains the identity split; this architecture explains the separate CloudFront delivery control.
Should Cognito replace WordPress as the application identity layer?
See Use Amazon Cognito Instead of WordPress as the Application Identity Layer when login must extend beyond WordPress itself to APIs, static frontends or other application surfaces.
Can existing SAML or OIDC identity providers still be used?
See Connect WordPress to Existing SAML and OIDC Identity Providers Without Building Separate Login Flows for the federation use case. Cognito can remain the identity hub while the protected-static layer consumes the resulting authenticated state.
Does static login automatically authorize APIs?
No. Signed static access and protected API actions are separate boundaries. The backend must independently validate JWT, IAM or another supported authorization mechanism.
Start with the access problem
Add login without bringing the WordPress session layer back
Use the secure-static solution for the buyer problem, then use this architecture when selected files or paths also need CloudFront-enforced protection.