Architecture · Identité applicative
Architecture d’identité Cognito pour l’exploitation de WordPress
Considérez Cognito comme un sous-système d’identité, pas comme un simple écran de connexion : authentification dans le navigateur, fédération, groupes, contexte des jetons et identifiants AWS facultatifs restent séparés du contenu et des sessions WordPress.
Page WordPress → interface Gatey
↓ navigateur
Amazon Cognito User Pool
├→ fournisseurs sociaux / SAML / OIDC
├→ MFA + parcours de profil
├→ groupes / contexte des jetons
└→ Identity Pool facultatif
↓
API protégées / accès statique
Frontière d’identité
WordPress affiche l’expérience ; Cognito détient l’identité applicative
Gatey fournit l’expérience frontend, tandis que Cognito authentifie les utilisateurs et émet des artefacts d’identité que d’autres services peuvent valider. La connexion fonctionne ainsi sur WordPress dynamique ou statique sans faire de la table des utilisateurs WordPress la source de l’identité applicative.
Navigateur du visiteur
→ authentificateur Gatey
→ Cognito User Pool
├→ connexion / inscription / MFA / profil
├→ fédération SAML / OIDC / sociale
└→ contexte des groupes et jetons
├→ API autorisées par JWT
├→ identifiants IAM facultatifs
└→ décision du signataire pour l’accès statique protégé
Frontière d’autorisation Une authentification réussie n’accorde pas un accès universel. Les API et ressources statiques protégées doivent appliquer leurs propres scopes, politiques IAM ou accès signé à partir du contexte d’identité fourni par Cognito.
Ce que le modèle provisionne
La pile d’identité comprend plus qu’un User Pool. Cet inventaire présente le client navigateur, les options de fédération et de domaine, les déclencheurs de cycle de vie, les identifiants AWS facultatifs et les sorties formant la frontière applicative.
| Composant | Raison d’être | Choix de conception principal | Note d’exploitation |
|---|---|---|---|
| User Pool + App Client | Annuaire principal et client OAuth pour la connexion WordPress dans le navigateur | Aucun secret client ; client public compatible code ou SRP | La pile peut le créer ou se rattacher à un pool existant selon le mode du modèle. |
| Domaine personnalisé facultatif | Connexion aux couleurs de la marque et callbacks OAuth | Certificat ACM et alias Route53 facultatif si la hosted zone est disponible | La propriété DNS et du certificat doit être explicite avant la production. |
| Identity Pool | Échange les utilisateurs Cognito authentifiés contre des identifiants AWS pour les API signées IAM | Séparer AuthenticatedRole de RegisteredRole | Utile pour appeler API Gateway protégé par IAM depuis un frontend statique. |
| Custom Email Sender | Remplace les e-mails Cognito simples par des modèles HTML et parcours de marque | Modèles dans S3 ; SES si configuré, sinon Cognito peut rester le fallback | Traitez les modèles comme des actifs versionnés, pas comme du texte saisi dans la console. |
| Déclencheur Pre Sign-Up | Valide la qualité de l’inscription avant l’entrée dans le pool | reCAPTCHA facultatif, domaines approuvés et liaison des IdP externes par e-mail | Les échecs doivent être compréhensibles dans le frontend et suffisamment journalisés. |
| Déclencheur Pre Token Generation | Projette l’appartenance aux groupes dans les scopes de l’access token | Ajouter des scopes tels que sc.group.registered ou sc.group.admin | Rend les contrôles de scopes API Gateway plus déclaratifs. |
| Déclencheur Post Confirmation | Place les utilisateurs confirmés dans le groupe Registered | Traiter uniquement les vraies confirmations d’inscription | Sépare « authentifié » de « suffisamment inscrit pour appeler les API ». |
| Outputs | Permettent aux autres piles et extensions de consommer les artefacts d’identité | Exposer IDs du pool et du client, domaine, rôles, groupes et ARN de fonctions | Les outputs sont le contrat entre cette pile et le reste de la plateforme. |
Modèle de jetons et d’autorisation
Cognito expose plusieurs artefacts d’identité aux rôles différents. Ce tableau sépare authentification navigateur, groupes, scopes, identifiants AWS temporaires et autorisation côté service.
| Couche | Artefact | Ce qu’il prouve | Ce qu’il ne doit pas faire |
|---|---|---|---|
| Gatey / navigateur | Jetons Cognito et état d’authentification local | L’utilisateur a terminé le parcours Cognito configuré | Stocker des secrets sur le serveur WordPress ou transmettre les mots de passe par PHP. |
| Groupes du User Pool | registered, admin ou groupes propres au projet | L’utilisateur appartient à un rôle métier | Devenir le seul point d’application à l’exécution. |
| Scopes de l’access token | sc.group.<group> | Le jeton transporte un contexte de rôle lisible par l’API | Remplacer l’autorisation backend lorsque la propriété d’une ressource compte. |
| Rôle Identity Pool | AuthenticatedRole ou RegisteredRole | Le navigateur peut obtenir des identifiants AWS temporaires pour les actions autorisées | Accorder des permissions larges au niveau du compte. |
| Méthode API Gateway | Scope Cognito ou autorisation IAM | La route applique l’identité à la frontière du service | Dépendre de boutons masqués ou de restrictions uniquement en CSS. |
Modes de défaillance opérationnels
Les échecs d’identité ressemblent souvent à de simples problèmes de connexion alors que la cause concerne e-mail, fédération, scopes ou DNS. Ce tableau relie les symptômes à la frontière opérationnelle à examiner.
| Défaillance | Symptôme visible | Cause probable | Orientation du runbook |
|---|---|---|---|
| reCAPTCHA refuse l’inscription | L’utilisateur ne peut pas créer de compte | Clé ou secret incorrect, jeton périmé, score faible ou action différente | Vérifiez le chemin du jeton clientMetadata, le secret SSM, le seuil et les logs Lambda. |
| L’e-mail personnalisé n’arrive pas | Aucun e-mail de confirmation ou mot de passe | Identité SES non vérifiée, sandbox, lecture du modèle impossible ou FROM différent | Vérifiez l’identité SES, les logs CloudWatch, la clé S3 du modèle et le fallback. |
| La connexion sociale crée des doublons | Le même e-mail apparaît sous plusieurs identités fournisseur | Liaison des IdP externes désactivée ou en échec | Examinez les logs Pre Sign-Up et les permissions AdminLinkProviderForUser. |
| Appel API refusé après connexion | Le frontend authentifie, mais l’API renvoie 401/403 | Utilisateur absent de Registered, scopes manquants, rôle non mappé ou authorizer incorrect | Contrôlez scopes, groupes, logs Post Confirmation et authorizer API Gateway. |
| Le domaine personnalisé échoue | Hosted UI ou domaine de callback inaccessible | Région ou validation du certificat, zone Route53 différente ou cible d’alias | Validez le certificat ACM, la propriété DNS et l’état du domaine Cognito. |
Parcours de mise en œuvre
Construisez l’identité autour de la frontière applicative, pas d’une session WordPress
Le travail d’exploitation utile commence après la création du User Pool : fédération, cycle de vie, autorisation et configuration reproductible.
- Définissez le propriétaire de l’identité — Gardez WordPress centré sur le contenu et la présentation. Utilisez Cognito lorsque la même identité visiteur doit s’étendre aux pages statiques, API ou autres surfaces applicatives.
- Configurez les parcours nécessaires de connexion et de fédération — Activez avec Cognito et Gatey uniquement les parcours de connexion, inscription, MFA, profil, fournisseurs sociaux, SAML ou OIDC réellement nécessaires au projet.
- Associez l’identité aux autorisations d’exécution — Utilisez claims, scopes, groupes ou identifiants IAM facultatifs afin que les backends autorisent les actions indépendamment de leur visibilité dans le frontend.
- Testez le cycle de vie et les échecs — Vérifiez confirmation, récupération du mot de passe, MFA, connexion du fournisseur, changement de groupe, expiration du jeton et refus API séparément du rendu des pages.
Quand Cognito doit détenir la couche d’identité applicative
Bon choix
L’identité doit dépasser WordPress
- Les mêmes utilisateurs doivent se connecter à un frontend statique ou à des pages où WordPress PHP ne traite pas la requête.
- L’identité frontend doit autoriser des API, ressources protégées ou autres surfaces applicatives.
- L’organisation possède déjà ou prévoit des exigences de fédération sociale, SAML ou OIDC.
Conserver l’authentification native WordPress
Les sessions WordPress peuvent être plus simples lorsque
- seuls wp-admin ou des pages WordPress dynamiques ordinaires exigent des utilisateurs authentifiés.
- aucune application externe, API protégée ou interface statique n’a besoin de la même identité.
- les extensions existantes dépendent directement des utilisateurs et sessions WordPress et qu’aucune raison métier ne justifie un sous-système distinct.
Guides de décision
Décisions d’identité prises en charge par cette architecture
Quand Amazon Cognito doit-il remplacer WordPress comme couche d’identité ?
Consultez Amazon Cognito comme couche d’identité à la place de WordPress. WordPress reste le CMS et Cognito détient l’identité des visiteurs pour l’application élargie.
Comment connecter des fournisseurs SAML ou OIDC existants ?
Consultez Connecter WordPress aux fournisseurs SAML et OIDC existants. Cognito sert de centre de fédération et Gatey conserve une seule expérience de connexion frontend.
Comment cela fonctionne-t-il sur WordPress statique ?
Consultez Ajouter la connexion à WordPress statique sans réintroduire les sessions PHP. La connexion Cognito dans le navigateur survit à la publication statique car elle ne dépend pas d’une session PHP WordPress.
Quelle différence entre fichiers statiques protégés et API protégées ?
Pour la diffusion statique, consultez Sécuriser WordPress statique avec des cookies signés CloudFront. Les API doivent valider séparément JWT, IAM ou un autre mécanisme pris en charge.
Commencez par la décision d’identité
Utilisez Cognito lorsque l’identité du visiteur doit survivre à la requête WordPress
Choisissez le guide sur l’identité applicative pour la décision principale, ou le guide SSO lorsque la fédération avec des fournisseurs existants constitue l’exigence centrale.