SSO WordPress avec Amazon Cognito et Gatey | Guide de connexion sociale et d’entreprise

Avant la configuration

Trois décisions structurent toute la conception du SSO

Architecture

Pourquoi utiliser Cognito comme hub d’identité ?

Un site WordPress peut avoir besoin d’une connexion sociale fluide pour ses clients et d’un SSO d’entreprise pour ses employés, partenaires ou donneurs d’ordre. Configurer chaque fournisseur directement dans WordPress crée plusieurs parcours de rappel distincts et complique la coordination des modifications ultérieures.

Cognito place ces fournisseurs derrière un seul User Pool. Gatey affiche ensuite l’expérience côté WordPress, tandis que l’authentification, la MFA, les attributs utilisateur, les groupes et l’émission des jetons restent dans Cognito.

• Utilisez un seul User Pool comme annuaire d’identités de l’application.
• Ajoutez chaque fournisseur externe à Cognito au lieu de reconstruire le parcours de connexion WordPress.
• Laissez Gatey présenter les options de connexion obtenues dans WordPress.

Cette séparation est particulièrement utile lorsque le même parcours d’identité doit fonctionner à la fois sur une installation WordPress dynamique et sur un frontend publié de manière statique. Pour la frontière au niveau de l’application, consultez comment utiliser Amazon Cognito comme couche d’identité de l’application.

Fondations Cognito

Comment configurer le User Pool et l’App Client ?

Commencez par un Cognito User Pool et un client d’application destiné au navigateur. Le client d’application ne doit pas générer de secret. Activez le flux authorization code grant et enregistrez exactement les URL de rappel et de déconnexion utilisées par le site.

Ne demandez que les scopes nécessaires au frontend. Une base courante comprend openid, email et profile. Ajoutez aws.cognito.signin.user.admin uniquement si l’expérience de compte nécessite les opérations sur le profil utilisateur Cognito couvertes par ce scope.

• Faites correspondre exactement les URL de rappel, y compris le protocole, le nom d’hôte, le chemin et la barre oblique finale.
• Activez chaque fournisseur d’identité que le client d’application doit proposer.
• Créez un domaine Cognito pour les points de terminaison d’autorisation gérés.

Testez le parcours d’autorisation Cognito avant de mettre en forme l’expérience WordPress. Un fournisseur qui échoue dans Cognito échouera également lorsqu’il sera lancé via Gatey.

Fournisseurs d’identité

Comment intégrer les fournisseurs sociaux et d’entreprise ?

Cognito peut fédérer des fournisseurs sociaux courants tels que Google, Facebook, Apple et Amazon. Les connexions d’entreprise passent généralement par OIDC ou SAML, ce qui permet au fournisseur d’identité d’entreprise existant de rester la source des identités des employés ou partenaires.

Le mappage des attributs est la partie la plus susceptible de provoquer des problèmes subtils. Mappez l’adresse e-mail, le prénom, le nom et un identifiant fournisseur stable lorsqu’ils sont disponibles. Vérifiez les attributs requis par le User Pool avant d’activer le fournisseur pour les utilisateurs en production.

• Testez chaque fournisseur séparément via le parcours d’autorisation hébergé par Cognito.
• Examinez les claims renvoyés et les attributs mappés au lieu de supposer que les valeurs par défaut du fournisseur correspondent.
• Limitez les scopes demandés au fournisseur et les attributs Cognito au strict nécessaire pour l’application.

Les noms d’affichage des fournisseurs sont des choix de présentation dans Gatey ; les identifiants réels des fournisseurs et la configuration de confiance restent dans Cognito. Pour le parcours de fédération, consultez comment connecter WordPress à des fournisseurs d’identité SAML et OIDC existants.

Configuration WordPress

Comment connecter Cognito à Gatey ?

Dans l’administration WordPress, ouvrez les réglages SmartCloud et configurez Gatey avec la région AWS, l’ID du User Pool, l’ID de l’App Client, le domaine Cognito, les scopes OAuth, les mécanismes de connexion et les attributs d’inscription utilisés par le site.

Ajoutez ensuite le bloc Gatey Authenticator à la page de connexion ou de compte. Les fournisseurs sociaux intégrés peuvent être activés dans les réglages du bloc, tandis que les fournisseurs SAML et OIDC personnalisés peuvent être présentés avec les libellés requis par le projet.

• Créez et testez d’abord une page de connexion ou de compte dédiée.
• Vérifiez séparément les parcours d’inscription, de confirmation, de récupération du mot de passe, de MFA et de profil.
• N’ajoutez les boutons de fournisseurs personnalisés qu’après confirmation de leurs identifiants Cognito.

Gatey contrôle la couche de présentation WordPress, mais ne déplace ni les secrets des fournisseurs, ni les mots de passe, ni l’annuaire d’utilisateurs Cognito dans WordPress.

Accès aux API AWS

Quand faut-il un Identity Pool et un rôle IAM ?

Un User Pool suffit lorsque le site n’a besoin que de la connexion, des écrans de compte et d’API autorisées par JWT. Un Identity Pool devient pertinent lorsque les utilisateurs authentifiés dans le navigateur doivent recevoir des identifiants AWS temporaires et signer les requêtes avec AWS IAM.

Les rôles IAM associés ne doivent autoriser que les actions et ressources nécessaires à ce frontend. L’autorisation fondée sur les groupes ou les claims peut encore restreindre le comportement de l’application, mais elle ne doit pas compenser une stratégie IAM trop permissive.

• Utilisez l’autorisation JWT lorsque l’API peut valider directement les jetons Cognito.
• Ajoutez un Identity Pool uniquement pour les cas nécessitant des identifiants AWS et une signature IAM.
• Limitez execute-api et les autres autorisations aux API et actions prévues.

Traitez l’authentification de l’identité et l’autorisation des ressources comme deux décisions d’architecture distinctes. Une connexion réussie ne doit pas impliquer automatiquement un accès étendu aux services AWS.

Contrôle avant lancement

Que faut-il tester avant de publier le parcours SSO ?

Faites suivre à chaque fournisseur la même séquence qu’un utilisateur réel : commencer depuis WordPress, s’authentifier auprès du fournisseur, revenir à l’URL de rappel enregistrée, examiner les données du compte obtenu, se déconnecter, puis recommencer avec un compte existant.

Testez également les parcours d’échec. Des URL de redirection qui ne correspondent pas, l’absence du scope openid, un mappage d’e-mail incomplet, un secret de client d’application et le remplacement prématuré de wp-login sont des causes fréquentes d’échecs SSO difficiles à interpréter.

• Confirmez les URL exactes de rappel et de déconnexion dans Cognito et WordPress.
• Confirmez les claims requis, les attributs mappés, les groupes et les rôles WordPress.
• Testez une voie de récupération administrateur avant de modifier la connexion par défaut.

Une fois le parcours d’identité fiable, le style et les libellés des fournisseurs peuvent être ajustés sans modifier les relations de confiance sous-jacentes. Pour une diffusion statique, consultez comment maintenir la connexion sans rétablir les sessions PHP.