Autenticación de WordPress
SSO de WordPress con Amazon Cognito y Gatey | Guía de inicio de sesión social y empresarial
Amazon Cognito puede actuar como un único centro de identidad para proveedores sociales y para el proveedor SAML u OIDC existente de una organización. Gatey integra esa capa de identidad en WordPress mediante experiencias configurables de inicio de sesión, registro, MFA y gestión de cuentas, que también pueden seguir funcionando después de una exportación estática.
Antes de configurar
Tres decisiones definen todo el diseño del SSO
Elija el centro de identidad
Mantenga los proveedores sociales y empresariales detrás de un único Cognito User Pool para que las aplicaciones utilicen un conjunto coherente de usuarios, atributos, grupos y tokens.
Utilice un cliente de aplicación público
Un frontend de WordPress o estático que se ejecuta en el navegador no puede guardar de forma segura un secreto de cliente. Cree el cliente de aplicación de Cognito sin secreto.
Defina el límite de autorización
El inicio de sesión con Cognito puede limitarse a sesiones del navegador y JWT, o continuar mediante un Identity Pool cuando el frontend deba obtener credenciales temporales de AWS.
Arquitectura
¿Por qué utilizar Cognito como centro de identidad?
Un sitio de WordPress puede necesitar un acceso social sencillo para clientes y SSO empresarial para empleados, socios o clientes corporativos. Configurar cada proveedor directamente en WordPress crea varios flujos de callback separados y dificulta la coordinación de cambios posteriores.
Cognito coloca esos proveedores detrás de un único User Pool. Gatey presenta entonces la experiencia orientada a WordPress, mientras que la autenticación, la MFA, los atributos de usuario, los grupos y la emisión de tokens permanecen en Cognito.
- Utilice un único User Pool como directorio de identidades de la aplicación.
- Añada cada proveedor externo a Cognito en lugar de reconstruir el flujo de inicio de sesión de WordPress.
- Permita que Gatey presente en WordPress las opciones de acceso resultantes.
Esta separación resulta especialmente útil cuando la misma ruta de identidad debe funcionar tanto en una instalación dinámica de WordPress como en un frontend publicado de forma estática. Para conocer el límite en el nivel de la aplicación, consulte cómo utilizar Amazon Cognito como capa de identidad de la aplicación.
Base de Cognito
¿Cómo deben configurarse el User Pool y el App Client?
Comience con un Cognito User Pool y un cliente de aplicación orientado al navegador. El cliente de aplicación no debe generar ningún secreto. Active el flujo authorization code grant y registre exactamente las URL de callback y cierre de sesión que utiliza el sitio.
Solicite únicamente los scopes que necesita el frontend. Una base habitual incluye openid, email y profile. Añada aws.cognito.signin.user.admin solo cuando la experiencia de cuenta requiera operaciones de perfil de usuario de Cognito cubiertas por ese scope.
- Las URL de callback deben coincidir exactamente, incluidos el protocolo, el nombre de host, la ruta y la barra final.
- Active todos los proveedores de identidad que deba ofrecer el cliente de aplicación.
- Cree un dominio de Cognito para los endpoints de autorización administrados.
Pruebe el flujo de autorización de Cognito antes de diseñar la experiencia de WordPress. Un proveedor que falle en Cognito también fallará cuando se inicie mediante Gatey.
Proveedores de identidad
¿Cómo se integran los proveedores sociales y empresariales?
Cognito puede federar proveedores sociales habituales como Google, Facebook, Apple y Amazon. Las conexiones empresariales normalmente se incorporan mediante OIDC o SAML, lo que permite que el proveedor de identidad corporativo existente siga siendo la fuente de las identidades de empleados o socios.
El mapeo de atributos es la parte más propensa a causar problemas sutiles. Mapee el correo electrónico, el nombre, los apellidos y un identificador estable del proveedor cuando estén disponibles. Confirme qué atributos exige el User Pool antes de activar el proveedor para usuarios de producción.
- Pruebe cada proveedor de forma independiente mediante la ruta de autorización alojada por Cognito.
- Revise los claims devueltos y los atributos mapeados, en lugar de asumir que los valores predeterminados del proveedor coinciden.
- Limite los scopes solicitados al proveedor y los atributos de Cognito al mínimo que permita la aplicación.
Los nombres visibles de los proveedores son opciones de presentación en Gatey; los identificadores reales de los proveedores y la configuración de confianza siguen perteneciendo a Cognito. Para conocer la ruta de federación, consulte cómo conectar WordPress a proveedores de identidad SAML y OIDC existentes.
Ajustes de los proveedores de identidad social
| Proveedor | Credenciales | Scopes | Mapeo habitual |
|---|---|---|---|
| ID de cliente OAuth + secreto | openid email profile |
email → email, family_name → family_name, given_name → given_name, sub → username |
|
| ID de aplicación + secreto | email public_profile |
email → email, last_name → family_name, first_name → given_name, id → username |
|
| Apple | ID de servicios, clave, ID de equipo | openid email name |
Mapee email; tenga en cuenta los correos de retransmisión privada de Apple en la experiencia de usuario. |
| Amazon | Perfil de seguridad de Login with Amazon | profile (+ email si se desea) |
email → email, name → given/family cuando estén disponibles |
Configuración de WordPress
¿Cómo se conecta Cognito con Gatey?
En la administración de WordPress, abra el área de ajustes de SmartCloud y configure Gatey con la región de AWS, el ID del User Pool, el ID del App Client, el dominio de Cognito, los scopes de OAuth, los mecanismos de acceso y los atributos de registro utilizados por el sitio.
A continuación, añada el bloque Gatey Authenticator a la página de inicio de sesión o de cuenta. Los proveedores sociales integrados pueden activarse en los ajustes del bloque, mientras que los proveedores SAML y OIDC personalizados pueden presentarse con las etiquetas que requiera el proyecto.
- Cree y pruebe primero una página específica de inicio de sesión o cuenta.
- Verifique por separado los flujos de registro, confirmación, recuperación de contraseña, MFA y perfil.
- Añada botones de proveedores personalizados solo después de confirmar sus identificadores en Cognito.
Gatey controla la capa de presentación de WordPress, pero no traslada a WordPress los secretos de los proveedores, las contraseñas ni el directorio de usuarios de Cognito.
Acceso de administración
Mapee un grupo de administradores antes de sustituir wp-login.php
No redirija ni sustituya el inicio de sesión nativo de WordPress hasta que al menos una identidad de Cognito probada esté mapeada al rol de administrador de WordPress necesario. Verifique el flujo completo en una sesión separada del navegador y conserve una vía de recuperación para que un error del proveedor o del mapeo no bloquee a todos los administradores.
Acceso a API de AWS
¿Cuándo se necesitan un Identity Pool y un rol de IAM?
Un User Pool es suficiente cuando el sitio solo necesita inicio de sesión, pantallas de cuenta y API autorizadas mediante JWT. Un Identity Pool es pertinente cuando los usuarios autenticados en el navegador deben recibir credenciales temporales de AWS y firmar solicitudes mediante AWS IAM.
Los roles de IAM asociados solo deben conceder las acciones y los recursos que necesite ese frontend. La autorización basada en grupos o claims puede restringir aún más el comportamiento de la aplicación, pero no debe compensar una política de IAM demasiado amplia.
- Utilice autorización JWT cuando la API pueda validar directamente los tokens de Cognito.
- Añada un Identity Pool únicamente para casos que requieran credenciales de AWS y firma de IAM.
- Limite execute-api y otros permisos a las API y acciones previstas.
Trate la autenticación de identidad y la autorización de recursos como decisiones de diseño separadas. Un inicio de sesión correcto no debe implicar automáticamente un acceso amplio a los servicios de AWS.
Comprobación previa al lanzamiento
¿Qué debe probarse antes de publicar el flujo de SSO?
Haga pasar a cada proveedor por la misma secuencia que seguirá un usuario real: comenzar en WordPress, autenticarse con el proveedor, volver al callback registrado, revisar los datos de la cuenta resultante, cerrar sesión y repetir el proceso con una cuenta existente.
Pruebe también las rutas de error. Las discrepancias en las URL de redirección, la ausencia del scope openid, el mapeo incompleto del correo electrónico, un secreto de cliente de aplicación y la sustitución prematura de wp-login son causas habituales de fallos de SSO difíciles de interpretar.
- Confirme las URL exactas de callback y cierre de sesión en Cognito y WordPress.
- Confirme los claims necesarios, los atributos mapeados, los grupos y los roles de WordPress.
- Pruebe una vía de recuperación de administración antes de cambiar el inicio de sesión predeterminado.
Cuando la ruta de identidad sea fiable, podrá ajustar el estilo y las etiquetas de los proveedores sin cambiar las relaciones de confianza subyacentes. Para la entrega estática, consulte cómo mantener operativo el inicio de sesión sin restablecer las sesiones de PHP.
Configure primero la ruta de identidad
Pruebe Cognito antes de diseñar el inicio de sesión de WordPress
Cree y verifique primero el User Pool, el cliente de aplicación público, los mapeos de proveedores, los callbacks y los límites de los roles. Después, utilice Gatey para situar la experiencia de inicio de sesión y cuenta resultante donde esperan encontrarla los usuarios de WordPress.