Gatey for WordPress
Amazon Cognito authentication without turning WordPress into the identity server
Add sign-in, registration, password recovery, MFA, profile editing, and SSO through native WordPress blocks. Authentication runs in the browser against your own Amazon Cognito User Pool, so the same experience can keep working after a static export.
Best for
Cognito-first WordPress identity
Use Gatey when Amazon Cognito should be the primary identity store, the login experience must survive a static export, WordPress should not store a Cognito client secret, or the frontend needs Cognito JWT or AWS IAM access to protected APIs.
Not designed for
Gatey is not the primary fit when the project explicitly wants WordPress-native users and WordPress authentication to remain the main identity system. Use the Cognito vs WordPress-native authentication comparison when that ownership decision is still open.
Why Gatey
Keep the WordPress experience while moving identity to Cognito
Gatey separates the login interface from the identity runtime. Editors control where authentication appears; the customer’s Cognito configuration controls users, tokens, MFA, and identity providers.
01
Visual authentication flows
Place sign-in, sign-up, password reset, MFA, profile, and account experiences with Gutenberg blocks, Elementor widgets, or shortcodes.
02
Social and enterprise SSO
Use Cognito-supported Facebook, Google, Amazon, and Apple providers, or connect custom SAML and OIDC identity providers where the plan and Cognito setup support them. See the SAML/OIDC SSO solution when WordPress must join an existing identity environment without building a separate login flow.
03
Static-site compatible
Because the runtime is browser-based, Gatey can continue authenticating visitors when WordPress is published as static files to S3, CloudFront, or another static host. The static WordPress login guide explains how to keep authentication without restoring PHP sessions.
04
Identity-aware interfaces
Display Cognito attributes and use account groups or attributes in frontend logic, while protected APIs can be called with Cognito JWTs or AWS IAM signatures.
Capabilities
The frontend layer for a complete Cognito user journey
Registration and account recovery
Guide users through sign-up, confirmation, sign-in, password reset, and recovery states without building separate PHP handlers for each Cognito step.
MFA and profile management
Support multi-factor authentication, TOTP setup, attribute display, and profile editing through configurable account experiences embedded in the site.
Localized authentication UI
Choose from 22 built-in languages, use automatic LTR or RTL direction, override individual strings with custom JSON, or add another language without rebuilding the plugin.
Protected API integration
Use access or ID tokens for JWT-authorized APIs, or obtain AWS credentials through an Identity Pool for IAM-signed requests from the frontend.
Architecture
WordPress controls presentation; Cognito controls identity
Gatey does not proxy credentials through WordPress. The plugin loads the configured authentication interface, Cognito returns tokens to the browser, and optional APIs validate those tokens or IAM signatures independently. See the Cognito application identity solution for the buyer-level boundary and the Cognito identity architecture for the deeper runtime model.
VISITOR
│
▼
WORDPRESS / STATIC FRONTEND
│
└── Gatey blocks and account UI
│
▼
AMAZON COGNITO USER POOL
├── users and attributes
├── MFA and password flows
├── social / SAML / OIDC providers
└── JWT tokens
│
├── browser session and UI state
└── protected API calls
├── JWT authorization
└── IAM signature via Identity Pool
The Cognito User Pool, identity providers, users, and optional Identity Pool live in the AWS account selected for the project. WordPress retains only the non-secret configuration required to connect the frontend.
Evaluation questions
What teams usually need to know
Does Gatey store passwords or Cognito client secrets in WordPress?
No. User credentials are sent from the browser to Cognito, and Gatey is designed for app clients without a client secret. WordPress stores non-sensitive connection settings, not user passwords or session tokens.
Will authentication still work after a static export?
Yes. Gatey’s authentication logic runs in the browser and communicates directly with Cognito. Static delivery must include the required plugin assets and any periodically refreshed Pro configuration files.
Can Gatey use an existing Cognito User Pool?
Yes. Configure Gatey with the User Pool ID, App Client ID, region, and related settings for the pool you want the site to use. Deployment tools are optional, not required for the plugin itself.
Can it protect an entire static route?
Gatey provides identity in the frontend. To block unauthenticated delivery before a protected static file reaches the browser, pair Cognito login with CloudFront signed-cookie enforcement such as Static Site Guardian. See the signed-cookie architecture for the delivery boundary.
Use Cognito without rebuilding the frontend
Add a complete authentication journey to WordPress
Install Gatey, connect the site to your Cognito User Pool, and place the required account blocks. Add enterprise identity providers, protected APIs, or edge-protected static routes only when the project needs them.
Need hands-on help with Cognito, identity providers, protected APIs, or static-site access? Explore Gatey professional services on AWS Marketplace.