Comparaison · Architecture d’identité pour WordPress
Gatey face aux extensions SSO pour WordPress
Une comparaison pratique pour les équipes qui doivent décider si WordPress reste le système d’identité, utilise une extension SSO générique ou s’appuie sur Amazon Cognito comme couche d’identité derrière WordPress et les frontends statiques.
En bref Une extension SSO traditionnelle peut convenir lorsque toute l’expérience reste dans WordPress dynamique et que le seul objectif est la connexion à WordPress. Gatey vise les projets où l’identité doit aussi fonctionner hors de PHP : exports statiques, fédération sociale/SAML/OIDC via Cognito, comptes frontend, API protégées par JWT/IAM et services d’exécution natifs d’AWS.
Pourquoi cela compte
Le SSO ne se limite pas à la page de connexion.
Pour de nombreux intranets, sites membres et portails WordPress dynamiques, configurer un fournisseur et associer quelques attributs aux utilisateurs WordPress suffit. La question d’architecture change lorsque WordPress n’est plus le seul environnement d’exécution.
Décision 01
Connexion à WordPress uniquement ou socle d’identité partagé ?
Une extension SSO classique connecte l’utilisateur à WordPress via un IdP externe. Gatey rend l’identité Cognito utilisable dans WordPress, sur les pages statiques et dans les API AWS.
Décision 02
Où résident utilisateurs, fédération et jetons ?
Dans le modèle Gatey, utilisateurs, groupes, MFA, fédération sociale/SAML/OIDC et jetons résident dans Cognito. WordPress conserve la configuration et affiche l’interface, au lieu de devenir la base d’identité principale.
Décision 03
L’identité doit-elle survivre à l’export statique ?
Un frontend statique ne peut pas dépendre de wp-login.php pour chaque interaction, et une application navigateur appelant API Gateway ne devrait pas utiliser un cookie de session PHP comme autorisation principale. Les jetons Cognito peuvent servir sur des pages statiques, derrière CloudFront et dans les API en aval.
Conséquence La question décisive est de savoir si seul un SSO vers WordPress est nécessaire, ou s’il faut un socle d’identité auquel WordPress participe et dont l’état connecté reste valable dans des frontends statiques et des services AWS.
Tableau de décision
Trois critères distinguent Gatey des extensions SSO WordPress classiques
Gatey répond à un besoin d’architecture plus large ; une extension SSO générique peut être plus simple lorsque seule la connexion à WordPress est requise.
| Critère de décision | Gatey | Extension SSO WordPress classique |
|---|---|---|
| Objectif principal et exécution | Le navigateur communique directement avec Cognito, afin que l’identité soit utilisable dans WordPress, sur des pages statiques et dans des API AWS. | Connecte l’utilisateur à WordPress via un IdP externe et dépend souvent du parcours de session WordPress/PHP. |
| Fédération et accès aux API | Amazon Cognito gère les fournisseurs sociaux, SAML et OIDC. La même couche peut protéger API Gateway et Lambda par validation JWT ou via Cognito Identity Pool/IAM. | L’extension associe généralement un fournisseur aux utilisateurs WordPress. L’autorisation d’API AWS séparées n’est habituellement pas sa fonction principale. |
| Frontend statique et meilleure adéquation | Conçu pour les portails statiques, WordPress soutenu par AWS, le contenu CloudFront protégé, les portails clients et un socle d’identité partagé. | Adapté au SSO WordPress dynamique classique lorsque l’intégration wp-admin/wp-login est l’exigence principale et que la session ne doit pas autoriser des environnements AWS séparés. |
Quand chaque approche convient-elle ?
Gatey convient mieux
Choisissez Gatey lorsque l’état d’identité doit rester valable au-delà de WordPress.
- Un frontend WordPress statique nécessite toujours connexion, inscription, réinitialisation du mot de passe, MFA ou modification du profil.
- Les composants frontend appellent des API AWS et nécessitent une autorisation JWT ou IAM ; l’identité doit fonctionner avec CloudFront, API Gateway, Lambda, des fonctions IA ou des workflows.
- Le client souhaite conserver identité, groupes et cycle de vie dans son propre compte AWS, tandis que l’agence réutilise le même modèle sur des projets WordPress, statiques et sans serveur.
L’extension SSO générique convient mieux
Choisissez une extension SSO traditionnelle lorsque WordPress reste toute l’application.
- Seul un SSO pour wp-admin ou un site membre WordPress dynamique classique est nécessaire.
- L’équipe ne souhaite ni posséder ni configurer d’infrastructure AWS et veut que l’extension masque toute l’infrastructure d’identité.
- La compatibilité statique, l’autorisation des API et la fédération Cognito ne sont pas nécessaires, ou le client impose déjà un SaaS d’identité managé avec connecteur WordPress.
FAQ de comparaison
Questions fréquentes lors de la comparaison de Gatey avec des extensions SSO WordPress
Gatey est-il uniquement une extension SSO ?
Non. Gatey couvre les cas d’usage SSO, mais le modèle plus large est une identité soutenue par Cognito pour WordPress, les frontends statiques et les API AWS.
Une extension SSO WordPress classique peut-elle être plus simple ?
Oui. Si le seul objectif est de connecter les utilisateurs à un site WordPress dynamique, une extension SSO traditionnelle peut être plus simple.
Gatey stocke-t-il des secrets client Cognito dans WordPress ?
Le parcours Cognito recommandé dans le navigateur utilise un client d’application public sans secret client. L’état d’identité sensible doit rester dans Cognito et la session du navigateur, pas dans les options WordPress.
Cela fonctionne-t-il après export statique et comment les API sont-elles protégées ?
Oui. Le frontend peut communiquer directement avec Cognito si les ressources exportées et les URL de rappel sont correctement configurées. API Gateway et Lambda peuvent valider les jetons ou identifiants IAM émis par Cognito sans demander à WordPress de relayer la requête.
Choisissez la bonne couche d’identité pour WordPress
Comparez le SSO limité à WordPress à un modèle centré sur Cognito.
Décidez selon l’endroit où l’identité doit être valable : uniquement dans WordPress dynamique ou aussi dans les frontends statiques, les comptes utilisateurs et les API AWS.