Decisión sobre identidad en WordPress
Amazon Cognito frente a la autenticación nativa de WordPress
La verdadera elección no consiste en decidir qué formulario de acceso tiene mejor aspecto. Se trata de determinar si la identidad del visitante pertenece a la aplicación WordPress o debe seguir siendo útil en páginas estáticas, proveedores federados y API protegidas.
Veredicto breve Utilice la autenticación nativa de WordPress cuando WordPress sea el límite de la aplicación. Elija Cognito con Gatey cuando la identidad de la aplicación deba sobrevivir a la publicación estática, federar proveedores sociales o SAML/OIDC, o autorizar API más allá de WordPress.
La decisión
Elija dónde seguirá siendo autoritativa la identidad
El acceso, el estado de la cuenta y la autorización de API resultan más difíciles de entender cuando se reparten entre varios sistemas sin un límite de identidad deliberado.
Entorno de ejecución
Las sesiones de WordPress dependen de que WordPress atienda la solicitud
Es lo natural en un WordPress dinámico, pero no encaja con un frontend público servido de forma estática que ya no llama a PHP para mostrar páginas.
Federación
Los proveedores externos de identidad amplían el límite de la aplicación
Los proveedores sociales y la federación SAML/OIDC personalizada se gestionan más fácilmente como identidad de aplicación cuando Cognito actúa como centro, en lugar de añadir una lógica de acceso independiente para cada superficie del sitio.
Autorización
Una sesión del sitio web no equivale a una autorización de API
Las API protegidas necesitan tokens, IAM u otro mecanismo aplicado por el backend que pueda validarse con independencia de los roles o botones visibles de WordPress.
Implicación de la decisión Conserve los usuarios nativos de WordPress cuando WordPress sea el límite de la aplicación. Traslade la identidad del visitante a Cognito cuando la misma identidad deba cruzar límites de frontend, API o federación.
Comparación directa
Compare el modelo operativo de identidad
Ambos modelos son válidos. La mejor opción depende de dónde deba seguir siendo útil el estado de autenticación después del acceso.
| Criterio de decisión | Amazon Cognito + Gatey | Autenticación nativa de WordPress |
|---|---|---|
| Entorno del frontend | Gatey autentica en el navegador contra Cognito, por lo que los flujos compatibles de acceso, registro, MFA, restablecimiento de contraseña y perfil pueden seguir funcionando tras una exportación estática. | Los usuarios y las sesiones nativas encajan en un entorno WordPress activo, donde PHP y la base de datos de WordPress siguen disponibles para las solicitudes autenticadas. |
| Federación y API | Cognito puede federar proveedores sociales y SAML/OIDC personalizados. Gatey puede usar la identidad resultante para acceder a API autorizadas mediante JWT o IAM. | Los plugins de WordPress pueden añadir patrones de SSO y API, pero el modelo nativo de usuarios y sesiones sigue centrado en WordPress salvo que se introduzca una arquitectura adicional. |
| Adecuación operativa | La mejor opción cuando la identidad es un servicio de aplicación compartido por páginas estáticas, API o varias superficies, y el equipo acepta operar Cognito. | La mejor opción cuando WordPress es la aplicación y los plugins existentes dependen de usuarios, roles y sesiones nativos. |
¿Qué modelo de identidad encaja con el proyecto?
Elija Cognito + Gatey
Cuando la identidad se extiende más allá de WordPress
- El frontend público puede ser estático mientras los visitantes siguen necesitando acceso, registro, MFA o gestión de perfil.
- Los mismos usuarios deben acceder a API protegidas o federarse mediante proveedores sociales, SAML u OIDC.
- WordPress debe seguir siendo el CMS y la capa de presentación, no la base de datos de identidad de la aplicación.
Elija la autenticación nativa de WordPress
Cuando WordPress ya es el límite de identidad adecuado
- El sitio sigue siendo una aplicación WordPress dinámica convencional.
- La afiliación o el comportamiento de los plugins depende directamente de los identificadores, roles y sesiones de usuario de WordPress.
- No se necesita un servicio de identidad separado, acceso para un frontend estático ni una identidad de API entre aplicaciones.
Guías centradas en el problema
Continúe a partir del problema de identidad
¿Cuándo debe Cognito convertirse en la capa de identidad de la aplicación?
Empiece por Usar Amazon Cognito en lugar de WordPress como capa de identidad de la aplicación y después consulte Arquitectura de identidad Cognito para el día 2 en WordPress para definir el límite de implementación.
¿Cómo añado acceso a un WordPress estático sin sesiones PHP?
Consulte Añadir acceso a un WordPress estático sin recuperar las sesiones PHP. Gatey ejecuta los flujos de autenticación compatibles en el navegador contra Cognito, por lo que la página pública no necesita una sesión de WordPress.
¿Cómo conecto proveedores de identidad SAML u OIDC existentes?
Utilice Conectar WordPress a proveedores de identidad SAML y OIDC existentes sin crear flujos de acceso separados. Los proveedores SAML/OIDC personalizados son una función de Gatey Pro configurada mediante Cognito.
¿Un acceso correcto autoriza automáticamente las API o los archivos protegidos?
No. Las API protegidas deben validar JWT, IAM u otro mecanismo de autorización de backend adecuado. Las rutas estáticas protegidas tienen un límite de acceso de CloudFront independiente.
Elija primero el límite de identidad
Utilice Cognito cuando la identidad deba seguir siendo útil fuera de la sesión de WordPress
Empiece por el problema de identidad de la aplicación o consulte la guía de acceso estático si el requisito inmediato es eliminar las sesiones PHP del frontend público.