Comparatif : Gatey face aux plugins SSO WordPress et fournisseurs d’identité populaires

Comment comparer

Trois questions évitent la plupart des erreurs de catégorie

Catégories de produits

Quels produits compare-t-on réellement ?

Gatey et Amazon Cognito constituent deux parties d’une même architecture. Gatey fournit les blocs WordPress, les écrans de compte, la localisation et l’intégration frontend. Cognito fournit l’annuaire d’utilisateurs, la fédération, la MFA, les groupes et les jetons.

Un plugin de connexion sociale répond à un besoin plus restreint. Un plugin SSO d’entreprise relie souvent WordPress à un fournisseur SAML ou OIDC existant. Des plateformes hébergées telles qu’Auth0 ou Okta exploitent le service d’identité. Keycloak est un fournisseur d’identité auto-hébergé. Un serveur OAuth WordPress inverse le sens et fait de WordPress la source d’identité d’autres applications.

• Couche cliente : présente la connexion et consomme les jetons.
• Passerelle de fédération : relie WordPress à un fournisseur externe.
• Fournisseur d’identité : gère les utilisateurs, stratégies, sessions et l’émission des jetons.

Ces catégories peuvent se chevaucher, mais les traiter comme des produits identiques conduit à des comparaisons trompeuses et à de mauvais choix de mise en œuvre.

Modèle d’exécution

Où s’exécute l’authentification ?

Avec Gatey, le navigateur communique directement avec le Cognito User Pool configuré. WordPress fournit l’interface et la configuration non sensible, mais n’a pas besoin de transmettre les mots de passe ni de conserver un secret de client d’application Cognito.

De nombreuses intégrations OAuth ou SAML natives de WordPress s’appuient sur l’environnement d’exécution WordPress pour les rappels, la création de sessions, l’attribution des rôles ou le stockage de la configuration. Cela peut parfaitement convenir à un site WordPress dynamique, mais devient une contrainte de conception lorsque le frontend public doit rester fonctionnel après une publication statique.

• Vérifiez où le fournisseur redirige le navigateur après l’authentification.
• Vérifiez si un secret client ou un certificat de signature doit être stocké dans WordPress.
• Vérifiez si le parcours de connexion dépend de PHP pour chaque session ou rappel.

Ne présumez pas que toutes les solutions suivent le même modèle. Consultez la documentation actuelle du plugin, du fournisseur et de l’édition évalués.

Besoins de fédération

Avez-vous besoin d’une connexion sociale, d’un SSO d’entreprise ou des deux ?

Un plugin spécialisé dans la connexion sociale est souvent le choix le plus simple lorsque le besoin se limite aux fournisseurs grand public et que le site reste une application WordPress conventionnelle. Il évite d’introduire une plateforme d’identité dont le projet n’aurait pas besoin par ailleurs.

Les projets d’entreprise accordent généralement plus d’importance à la fédération SAML ou OIDC, à l’association des attributs et des groupes, à la récupération administrative et à la responsabilité du cycle de vie. Cognito peut placer des fournisseurs sociaux et d’entreprise derrière un même User Pool, tandis que Gatey présente ces options dans WordPress.

• Choisissez un outil exclusivement social pour un besoin limité de connexion grand public.
• Choisissez une passerelle SSO d’entreprise lorsque WordPress doit rejoindre un environnement d’identité d’entreprise existant.
• Choisissez un concentrateur d’identité fédérée lorsque plusieurs applications ou types de fournisseurs doivent partager un modèle commun de jetons et d’utilisateurs.

Le bon choix dépend moins du nombre de logos de fournisseurs que de l’entité qui exploite l’annuaire d’identités et de la manière dont les utilisateurs passent d’une application à l’autre. Pour la fédération d’entreprise, découvrez comment connecter WordPress aux fournisseurs d’identité SAML et OIDC existants.

Autorisation des API

Les utilisateurs authentifiés appelleront-ils des API protégées ?

Gatey peut utiliser les jetons d’identification ou d’accès Cognito pour des points de terminaison autorisés par JWT. Lorsque le navigateur doit signer des requêtes AWS, un Cognito Identity Pool peut échanger la session authentifiée contre des identifiants temporaires associés à un rôle IAM.

D’autres fournisseurs d’identité hébergés ou auto-hébergés peuvent également émettre des jetons normalisés, mais le plugin WordPress peut s’arrêter à la création d’une session WordPress. Vérifiez que la combinaison choisie expose des jetons utilisables au frontend et comment les API en aval les valident.

• Session WordPress uniquement : suffisante pour du contenu WordPress dynamique protégé.
• Accès JWT : utile pour les API qui valident l’émetteur, le public, les portées et les déclarations.
• Identifiants AWS temporaires : utiles pour des requêtes de navigateur signées par IAM et étroitement limitées.

Un serveur OAuth WordPress correspond à un autre besoin : il est utile lorsque WordPress doit émettre des jetons vers d’autres applications plutôt que consommer l’identité d’un fournisseur externe.

Propriété et exploitation

Qui possède les utilisateurs et stratégies, et assume la disponibilité et la maintenance ?

Avec Gatey et Cognito, les ressources d’identité et les frais d’utilisation se trouvent dans le compte AWS du client. Une plateforme d’identité hébergée transfère davantage d’exploitation au fournisseur. Une plateforme auto-hébergée telle que Keycloak offre le contrôle, mais crée aussi des responsabilités d’infrastructure, de mise à niveau, de sauvegarde et de disponibilité.

Un plugin natif WordPress maintient l’administration près du CMS, mais le chemin d’authentification public peut hériter des caractéristiques de disponibilité et de sécurité de cet environnement WordPress. Aucun modèle n’est automatiquement supérieur ; chacun répartit différemment les responsabilités.

• Cloud du client : propriété directe avec configuration et facturation des services cloud.
• IdP hébergé : moins de travail d’infrastructure, avec une dépendance à la plateforme du fournisseur.
• IdP auto-hébergé : contrôle opérationnel maximal avec la plus grande charge de maintenance.

Incluez dans la comparaison la reprise après incident, l’accès administrateur, la surveillance, la rotation des certificats du fournisseur, le cycle de vie des utilisateurs et la responsabilité du support, pas seulement le temps d’installation. Pour la décision de propriété sous-jacente, comparez Amazon Cognito à l’authentification native de WordPress.

Guide pratique

Quelle approche convient à quel projet WordPress ?

Choisissez Gatey avec Cognito si le site utilise déjà AWS, doit prendre en charge un frontend statique, nécessite des fournisseurs sociaux et d’entreprise derrière un même User Pool ou doit appeler depuis le navigateur des API protégées par JWT ou IAM.

Choisissez un plugin SSO d’entreprise natif WordPress si le site reste dynamique, si l’objectif principal consiste à associer une identité d’entreprise existante aux rôles WordPress et si les administrateurs préfèrent gérer toute l’intégration dans le CMS.

• Choisissez un plugin spécialisé dans la connexion sociale pour quelques fournisseurs grand public et un environnement WordPress conventionnel.
• Choisissez une plateforme d’identité hébergée lorsque l’exploitation gérée par le fournisseur et la prise en charge de nombreuses applications importent plus que la propriété dans le cloud du client.
• Choisissez un IdP auto-hébergé lorsque l’organisation accepte la responsabilité opérationnelle nécessaire à un contrôle complet.

Choisissez un serveur OAuth WordPress lorsque WordPress doit devenir la source d’identité ou de jetons d’autres applications. Dessinez le chemin d’identité complet avant de choisir un plugin. Pour l’architecture applicative, découvrez comment utiliser Amazon Cognito comme couche d’identité applicative.

Liste de contrôle d’évaluation

Que doit vérifier une preuve de concept ?

Installez les solutions présélectionnées dans un environnement hors production et testez le parcours complet dans le navigateur plutôt que de vous fier à une matrice de fonctions. Incluez les nouveaux utilisateurs, les utilisateurs récurrents, la déconnexion, la récupération du mot de passe, la MFA, les erreurs de fournisseur, l’association de comptes et la récupération administrative.

Testez ensuite le modèle de déploiement prévu. Un site WordPress dynamique, un frontend statique, un portail membre et une application pilotée par API imposent des exigences différentes aux rappels, sessions, jetons et à la disponibilité du backend.

• Confirmez où sont stockés les identifiants, secrets, jetons et attributs utilisateur.
• Confirmez si nécessaire le comportement du site statique et la disponibilité des jetons d’API.
• Confirmez l’attribution des rôles, l’accès de récupération, les journaux et la responsabilité opérationnelle.

La meilleure solution SSO est celle dont le modèle d’identité correspond à l’application, et non celle dont la liste de fonctions est la plus longue.