Décision d’identité pour WordPress
Amazon Cognito ou authentification native de WordPress
Le véritable choix ne porte pas sur l’apparence du formulaire de connexion. Il consiste à décider si l’identité des visiteurs appartient à l’application WordPress ou doit rester utilisable sur des pages statiques, avec des fournisseurs fédérés et pour des API protégées.
Verdict en bref Utilisez l’authentification native de WordPress lorsque WordPress constitue la frontière de l’application. Choisissez Cognito avec Gatey lorsque l’identité applicative doit survivre à la publication statique, fédérer des fournisseurs sociaux ou SAML/OIDC, ou autoriser des API au-delà de WordPress.
La décision
Choisissez où l’identité reste l’autorité de référence
La connexion, l’état du compte et l’autorisation des API deviennent difficiles à comprendre lorsqu’ils sont répartis entre plusieurs systèmes sans frontière d’identité délibérée.
Environnement d’exécution
Les sessions WordPress dépendent de WordPress pour traiter la requête
Ce fonctionnement est naturel pour un WordPress dynamique, mais ne convient pas à un frontend public distribué statiquement qui n’appelle plus PHP pour afficher les pages.
Fédération
Les fournisseurs d’identité externes élargissent la frontière applicative
Les fournisseurs sociaux et la fédération SAML/OIDC personnalisée sont plus faciles à gérer comme une identité applicative commune lorsque Cognito joue le rôle de pivot, plutôt qu’en ajoutant une logique de connexion distincte à chaque interface du site.
Autorisation
Une session de site web n’équivaut pas à une autorisation d’API
Les API protégées ont besoin de jetons, d’IAM ou d’un autre mécanisme appliqué par le backend, vérifiable indépendamment des rôles ou boutons visibles dans WordPress.
Conséquence de la décision Conservez les utilisateurs natifs de WordPress lorsque WordPress constitue la frontière de l’application. Déplacez l’identité des visiteurs vers Cognito lorsqu’une même identité doit franchir les frontières du frontend, des API ou de la fédération.
Comparaison directe
Comparez les modèles d’exploitation de l’identité
Les deux modèles sont valables. Le meilleur choix dépend de l’endroit où l’état d’authentification doit rester utilisable après la connexion.
| Critère de décision | Amazon Cognito + Gatey | Authentification native de WordPress |
|---|---|---|
| Environnement du frontend | Gatey authentifie dans le navigateur auprès de Cognito. Les parcours pris en charge de connexion, d’inscription, de MFA, de réinitialisation du mot de passe et de profil peuvent donc continuer après un export statique. | Les utilisateurs et sessions natifs conviennent à un environnement WordPress actif, dans lequel PHP et la base de données WordPress restent disponibles pour les requêtes authentifiées. |
| Fédération et API | Cognito peut fédérer des fournisseurs sociaux et SAML/OIDC personnalisés. Gatey peut utiliser l’identité obtenue pour accéder à des API autorisées par JWT ou IAM. | Des extensions WordPress peuvent ajouter des modèles SSO et API, mais sans architecture supplémentaire, le modèle natif d’utilisateurs et de sessions reste centré sur WordPress. |
| Adéquation opérationnelle | Convient lorsque l’identité est un service applicatif partagé par des pages statiques, des API ou plusieurs interfaces, et que l’équipe accepte d’exploiter Cognito. | Convient lorsque WordPress est l’application et que les extensions existantes dépendent des utilisateurs, rôles et sessions natifs. |
Quel modèle d’identité convient au projet ?
Choisir Cognito + Gatey
Lorsque l’identité dépasse WordPress
- Le frontend public peut être statique tandis que les visiteurs ont encore besoin de se connecter, de s’inscrire, d’utiliser la MFA ou de gérer leur profil.
- Les mêmes utilisateurs doivent accéder à des API protégées ou se fédérer par l’intermédiaire de fournisseurs sociaux, SAML ou OIDC.
- WordPress doit rester le CMS et la couche de présentation, et non la base de données d’identité de l’application.
Choisir l’authentification native de WordPress
Lorsque WordPress constitue déjà la bonne frontière d’identité
- Le site reste une application WordPress dynamique classique.
- Les fonctions d’adhésion ou des extensions dépendent directement des identifiants, rôles et sessions des utilisateurs WordPress.
- Il n’est pas nécessaire de disposer d’un service d’identité distinct, d’une connexion sur un frontend statique ou d’une identité d’API interapplicative.
Guides centrés sur le problème
Poursuivez à partir du problème d’identité
Quand Cognito doit-il devenir la couche d’identité de l’application ?
Commencez par Utiliser Amazon Cognito à la place de WordPress comme couche d’identité de l’application, puis consultez Architecture d’identité Cognito au quotidien pour WordPress afin de définir la frontière de mise en œuvre.
Comment ajouter une connexion à un WordPress statique sans sessions PHP ?
Consultez Ajouter une connexion à un WordPress statique sans rétablir les sessions PHP. Gatey exécute dans le navigateur les parcours d’authentification pris en charge auprès de Cognito ; la page publique n’a donc pas besoin d’une session WordPress.
Comment connecter des fournisseurs d’identité SAML ou OIDC existants ?
Utilisez Connecter WordPress à des fournisseurs d’identité SAML et OIDC existants sans créer de parcours de connexion distincts. Les fournisseurs SAML/OIDC personnalisés sont une fonction de Gatey Pro configurée par l’intermédiaire de Cognito.
Une connexion réussie autorise-t-elle automatiquement les API ou les fichiers protégés ?
Non. Les API protégées doivent valider un JWT, IAM ou un autre mécanisme d’autorisation backend approprié. Les chemins statiques protégés possèdent une frontière d’accès CloudFront distincte.
Choisissez d’abord la frontière d’identité
Utilisez Cognito lorsque l’identité doit rester exploitable hors de la session WordPress
Commencez par le problème de l’identité applicative, ou consultez le guide sur la connexion statique si la priorité immédiate est de retirer les sessions PHP du frontend public.