Comparación · Arquitectura de identidad para WordPress
Gatey frente a plugins SSO para WordPress
Una comparación práctica para equipos que deben decidir si WordPress sigue siendo el sistema de identidad, consume un plugin SSO genérico o utiliza Amazon Cognito como capa de identidad detrás de WordPress y frontends estáticos.
Respuesta breve Un plugin SSO tradicional puede ser adecuado cuando toda la experiencia sigue en WordPress dinámico y el único objetivo es iniciar sesión en WordPress. Gatey está diseñado para proyectos donde la identidad también debe funcionar fuera de PHP: exportaciones estáticas, federación social/SAML/OIDC mediante Cognito, cuentas en el frontend, API protegidas por JWT/IAM y servicios de ejecución nativos de AWS.
Por qué importa
El SSO es más que una función de la página de acceso.
Para muchas intranets, sitios de membresía y portales dinámicos basta con configurar un proveedor y asociar atributos a usuarios de WordPress. La cuestión arquitectónica cambia cuando WordPress deja de ser el único entorno de ejecución.
Decisión 01
¿Solo acceso a WordPress o una base de identidad compartida?
Un plugin SSO típico inicia sesión en WordPress mediante un IdP externo. Gatey permite usar la identidad de Cognito en WordPress, páginas estáticas y API de AWS.
Decisión 02
¿Dónde residen usuarios, federación y tokens?
En el modelo de Gatey, usuarios, grupos, MFA, federación social/SAML/OIDC y tokens residen en Cognito. WordPress guarda configuración y muestra la interfaz, en vez de convertirse en la base principal de identidades.
Decisión 03
¿Debe sobrevivir la identidad a la exportación estática?
Un frontend estático no puede depender de wp-login.php en cada interacción, y una aplicación de navegador que llama a API Gateway no debería usar una cookie de sesión PHP como autorización principal. Los tokens de Cognito pueden servir en páginas estáticas, tras CloudFront y dentro de API posteriores.
Consecuencia La pregunta decisiva es si solo se necesita SSO en WordPress o una base de identidad en la que WordPress participe y cuyo estado de acceso también sea válido en frontends estáticos y servicios de AWS.
Tabla de decisión
Tres criterios separan Gatey de los plugins SSO habituales para WordPress
Gatey resuelve una necesidad arquitectónica más amplia; un plugin SSO genérico puede ser más sencillo cuando solo hace falta acceder a WordPress.
| Criterio de decisión | Gatey | Plugin SSO típico para WordPress |
|---|---|---|
| Objetivo principal y ejecución | El navegador se comunica directamente con Cognito, por lo que la identidad puede utilizarse en WordPress, páginas estáticas y API de AWS. | Inicia sesión en WordPress mediante un IdP externo y a menudo depende del flujo de sesión de WordPress/PHP. |
| Federación y acceso a API | Amazon Cognito gestiona proveedores sociales, SAML y OIDC. La misma capa puede proteger API Gateway y Lambda mediante validación JWT o patrones Cognito Identity Pool/IAM. | El plugin suele asociar un proveedor con usuarios de WordPress. Autorizar API independientes de AWS normalmente no es su función principal. |
| Frontend estático y mejor ajuste | Pensado para portales estáticos, WordPress con AWS, contenido protegido por CloudFront, portales de clientes y una base compartida de identidad. | Encaja con SSO clásico en WordPress dinámico cuando la integración wp-admin/wp-login es el requisito principal y la sesión no debe autorizar entornos de AWS separados. |
¿Cuándo encaja cada enfoque?
Gatey encaja mejor
Elija Gatey cuando el estado de identidad deba ser válido más allá de WordPress.
- Un frontend estático de WordPress sigue necesitando acceso, registro, restablecimiento de contraseña, MFA o edición del perfil.
- Los componentes del frontend llaman a API de AWS y necesitan autorización JWT o IAM; la identidad también debe funcionar con CloudFront, API Gateway, Lambda, IA o servicios de flujos.
- El cliente quiere que identidad, grupos y ciclo de vida residan en su propia cuenta de AWS, y la agencia desea repetir el mismo patrón en proyectos WordPress, estáticos y serverless.
El plugin SSO genérico encaja mejor
Elija un plugin SSO tradicional cuando WordPress siga siendo toda la aplicación.
- Solo necesita SSO para wp-admin o un sitio dinámico de membresía en WordPress.
- El equipo no quiere poseer ni configurar infraestructura de AWS y prefiere que el plugin oculte toda la infraestructura de identidad.
- No se necesitan compatibilidad estática, autorización de API ni federación con Cognito, o el cliente ya exige un SaaS gestionado de identidad con conector para WordPress.
Preguntas frecuentes de la comparación
Preguntas habituales al comparar Gatey con plugins SSO para WordPress
¿Gatey es únicamente un plugin SSO?
No. Incluye usos de SSO, pero el patrón más amplio es una identidad basada en Cognito para WordPress, frontends estáticos y API de AWS.
¿Puede ser más sencillo un plugin SSO normal para WordPress?
Sí. Si el único objetivo es que los usuarios accedan a un sitio dinámico de WordPress, un plugin SSO tradicional puede ser más sencillo.
¿Gatey guarda secretos de cliente de Cognito en WordPress?
El flujo recomendado de Cognito en el navegador utiliza un cliente público sin secreto. El estado sensible debe permanecer en Cognito y en la sesión del navegador, no en las opciones de WordPress.
¿Funciona tras la exportación estática y cómo ayuda con las API?
Sí. El frontend puede comunicarse directamente con Cognito si los recursos exportados y las URL de retorno están bien configurados. API Gateway y Lambda pueden validar tokens o credenciales IAM emitidos por Cognito sin pedir a WordPress que intermedie.
Elija la capa de identidad adecuada para WordPress
Compare el SSO limitado a WordPress con un modelo centrado en Cognito.
Decida según dónde deba ser válida la identidad: solo en WordPress dinámico o también en frontends estáticos, experiencias de cuenta y API de AWS.