Compare · WordPress identity architecture
Gatey vs WordPress SSO Plugins
A practical comparison for teams deciding whether WordPress should remain the identity system, consume a generic SSO plugin, or use Amazon Cognito as the identity layer behind WordPress and static frontends.
Short answer: A traditional WordPress SSO plugin can be the right choice when the whole experience remains dynamic WordPress and the goal is only to log users into WordPress. Gatey is designed for projects where identity must also work outside PHP: static exports, Cognito-hosted social/SAML/OIDC federation, frontend account components, JWT/IAM-secured APIs and AWS-native runtime services.
Why this matters
SSO is often treated as a login-page feature: install a plugin, configure an IdP, map a few attributes and let users sign in. That is enough for many intranets, membership sites and enterprise portals that remain fully dynamic WordPress.
The architectural question changes when WordPress is no longer the only runtime. A static frontend cannot depend on wp-login.php for every visitor interaction. A browser-side application calling API Gateway cannot use a PHP session cookie as its primary authorization model. A client portal served from CloudFront needs identity to be valid at the edge and inside downstream APIs.
Gatey approaches SSO from the Cognito side. WordPress renders the blocks, settings and editorial experience, but Amazon Cognito owns the user pool, federation, tokens and identity state. That makes identity portable across static pages, frontend components and AWS APIs.
Architecture and data flow
Visitor / editor
↓ Gatey block, shortcode or widget
Amazon Cognito User Pool
↓ social, SAML, OIDC, MFA, reset, profile
JWT tokens in browser session
↓
Static pages, WordPress integration, API Gateway, Lambda or signed-cookie services
This model separates identity from WordPress hosting. WordPress can still use the login state when needed, but the primary credentials and tokens are issued by Cognito. The same signed-in user can therefore interact with a static page, a protected CloudFront area or a serverless backend without forcing WordPress to proxy every request.
That distinction is especially important for agencies and CTOs. The question becomes: do we need SSO into WordPress, or do we need an identity backbone that WordPress can participate in?
Capability map
Cognito-first
User Pool as the source of identity
Users, groups, MFA, federation and tokens live in Cognito. WordPress stores configuration and renders the UI instead of becoming the main identity database.
Federation
Social, SAML and OIDC paths
Cognito can federate with social providers and enterprise IdPs. Gatey exposes this to WordPress through blocks, shortcodes, widgets and settings.
Static friendly
Login that survives static export
Because the frontend talks to Cognito directly, authentication can keep working after WordPress pages are exported to static hosting.
API authorization
JWT and IAM-aware runtime patterns
The same identity layer can protect API Gateway and Lambda endpoints through JWT validation or Cognito Identity Pool / IAM patterns.
Frontend account UX
Profile, account attributes and visibility
Gatey can show account attributes, profile flows and conditional frontend content based on authenticated user state.
Day-2 identity
Groups, scopes, hooks and triggers
The architecture can evolve toward group-based claims, custom scopes, post-confirmation group assignment and API-specific authorization patterns.
Decision table
| Decision axis | Gatey | Typical WordPress SSO plugin | Trade-off |
|---|---|---|---|
| Primary goal | Make Cognito identity usable across WordPress, static pages and AWS APIs | Log users into WordPress using an external IdP | Gatey is broader; a generic plugin may be simpler for WordPress-only login. |
| Runtime dependency | Browser talks to Cognito directly | Often depends on WordPress/PHP session flow | Direct Cognito flow is better for static exports; PHP session flow can be easier for classic sites. |
| Federation owner | Amazon Cognito handles social, SAML and OIDC providers | Plugin maps a provider to WordPress users | Cognito centralizes identity but requires AWS configuration. |
| API access | JWT/IAM-aware patterns for API Gateway and Lambda | Usually not the main product concern | Gatey is stronger when login must authorize cloud APIs, not only pages. |
| Static frontend | Designed to keep working after static export | Depends on plugin architecture and server-side callbacks | Static compatibility is a core difference. |
| Best fit | Static portals, AWS-backed WordPress, client identity backbone | Classic dynamic WordPress SSO | Choose the model based on where identity must be valid. |
How this differs from the usual approach
Generic SSO fit
When a generic SSO plugin is enough
Use a standard SSO plugin when WordPress remains the application, wp-admin/wp-login integration is the main requirement, and the logged-in session does not need to authorize separate AWS runtimes.
Cognito-first fit
When Gatey is better
Use Gatey when the identity state must travel beyond WordPress: static pages, protected CloudFront content, API Gateway, Lambda, AI features, workflows or client portals.
Migration rhythm
Adoption path
Start with Cognito sign-in and registration, add MFA and federation, then connect groups, account attributes and API authorization only where the project needs them.
When this is a good fit
- A static WordPress frontend still needs login, registration, password reset, MFA or profile editing.
- The site needs enterprise SSO through SAML or OIDC but should not tie identity exclusively to WordPress sessions.
- Frontend components call AWS APIs and need JWT or IAM-based authorization.
- A client wants identity, groups and user lifecycle to live in their AWS account.
- An agency wants the same identity pattern across WordPress, static delivery and serverless runtime services.
When not to use this
- You only need SSO for wp-admin or a traditional dynamic WordPress membership site.
- The team has no AWS ownership and wants the plugin to hide all identity infrastructure.
- The site does not need static compatibility, API authorization or Cognito federation.
- A managed identity SaaS with a WordPress connector is already mandated by the client.
Implementation path
- Decide whether the project needs WordPress login only or an identity layer shared by WordPress and AWS services.
- Create or attach a Cognito User Pool and configure app client settings, callback URLs and login mechanisms.
- Add Gatey blocks, shortcode or widget surfaces for sign-in, sign-up, account attributes and profile flows.
- Configure federation providers only after the base Cognito flow is stable.
- Map user groups and attributes to frontend visibility or API access rules where needed.
- If protecting APIs, define whether the endpoint validates JWTs directly or uses Cognito Identity Pool / IAM credentials.
- Test static export behavior separately from dynamic WordPress behavior, including refresh, logout and redirect flows.
Related resources
FAQ
Is Gatey only an SSO plugin?
No. It includes SSO use cases, but the larger pattern is Cognito-backed identity for WordPress, static frontends and AWS APIs.
Can a normal WordPress SSO plugin be simpler?
Yes. If the only goal is to let users sign into a dynamic WordPress site, a traditional SSO plugin can be simpler.
Does Gatey store Cognito client secrets in WordPress?
The recommended browser-based Cognito flow uses a public app client without a client secret. Sensitive identity state should stay in Cognito and the browser session, not in WordPress options.
Can this work after static export?
Yes. Gatey is designed so frontend authentication can talk directly to Cognito, which makes static exports possible when the exported assets and callback URLs are configured correctly.
How does this help with APIs?
Once Cognito issues tokens or IAM credentials, API Gateway and Lambda services can validate those credentials without asking WordPress to proxy the request.
Is this only for enterprise SSO?
No. It can be used for social login, normal email/password authentication, MFA, account pages and API-backed portal features as well.
Choose the right identity layer for WordPress
Compare WordPress-only SSO with a Cognito-first model that can also protect static frontends, account experiences and AWS APIs.