Architektur · Anwendungsidentität
Cognito-Identitätsarchitektur für den WordPress-Betrieb
Behandeln Sie Cognito als Identitätssubsystem und nicht nur als Anmeldeseite: Browser-Authentifizierung, Föderation, Gruppen, Token-Kontext und optionale AWS-Zugangsdaten bleiben von WordPress-Inhalten und -Sitzungen getrennt.
WordPress-Seite → Gatey-Oberfläche
↓ Browser
Amazon Cognito User Pool
├→ soziale / SAML- / OIDC-Anbieter
├→ MFA + Profilabläufe
├→ Gruppen / Token-Kontext
└→ optionaler Identity Pool
↓
geschützte APIs / statischer Zugriff
Identitätsgrenze
WordPress stellt die Erfahrung dar; Cognito besitzt die Anwendungsidentität
Gatey liefert die Frontend-Erfahrung, während Cognito Benutzer authentifiziert und Identitätsartefakte ausstellt, die andere Dienste validieren können. So bleibt die Anmeldung auf dynamischem oder statischem WordPress nutzbar, ohne die WordPress-Benutzertabelle zur Quelle der Anwendungsidentität zu machen.
Besucherbrowser
→ Gatey Authenticator
→ Cognito User Pool
├→ Anmeldung / Registrierung / MFA / Profil
├→ SAML- / OIDC- / soziale Föderation
└→ Gruppen- und Token-Kontext
├→ JWT-autorisierte APIs
├→ optionale IAM-Zugangsdaten
└→ Entscheidung des Signers für geschützte statische Inhalte
Autorisierungsgrenze Eine erfolgreiche Authentifizierung gewährt keinen universellen Anwendungszugriff. Geschützte APIs und statische Ressourcen müssen eigene Scope-, IAM- oder signierte Zugriffsrichtlinien mit dem von Cognito bereitgestellten Identitätskontext durchsetzen.
Was das Template bereitstellt
Der Identitätsstack umfasst mehr als einen User Pool. Diese Übersicht zeigt Browser-Client, Föderations- und Domainoptionen, Lebenszyklus-Trigger, optionale AWS-Zugangsdaten und Outputs, die gemeinsam die Anwendungsidentitätsgrenze bilden.
| Baustein | Zweck | Zentrale Designentscheidung | Betriebshinweis |
|---|---|---|---|
| User Pool + App Client | Primäres Benutzerverzeichnis und OAuth-Client für die browserbasierte WordPress-Anmeldung | Kein Client Secret; öffentlicher Client für Authorization Code oder SRP | Der Stack kann einen Pool anlegen oder je nach Template-Modus einen vorhandenen Pool anbinden. |
| Optionale benutzerdefinierte Domain | Markenbezogene Anmeldung und OAuth-Rückrufe | ACM-Zertifikat und optionaler Route53-Alias, wenn die Hosted Zone verfügbar ist | DNS- und Zertifikatseigentum müssen vor dem Produktivstart eindeutig sein. |
| Identity Pool | Tauscht authentifizierte Cognito-Benutzer gegen AWS-Zugangsdaten, wenn IAM-signierte APIs benötigt werden | AuthenticatedRole und RegisteredRole getrennt halten | Nützlich für IAM-geschützte API-Gateway-Aufrufe aus statischen Frontends. |
| Custom Email Sender | Ersetzt einfache Cognito-E-Mails durch HTML-Vorlagen und markengerechte Abläufe | Vorlagen liegen in S3; SES wird bei Konfiguration genutzt, sonst kann Cognito ausliefern | Vorlagen als versionierte Produktassets behandeln, nicht als Inline-Text in der Konsole. |
| Pre-Sign-Up-Trigger | Prüft die Qualität einer Registrierung, bevor der Benutzer in den Pool gelangt | Optionale reCAPTCHA-Prüfung, vertrauenswürdige Domains und Verknüpfung externer IdPs über E-Mail | Fehler müssen für die Frontend-UX verständlich und für die Diagnose ausreichend protokolliert sein. |
| Pre-Token-Generation-Trigger | Projiziert Gruppenmitgliedschaft in Access-Token-Scopes | Scopes wie sc.group.registered oder sc.group.admin hinzufügen | Ermöglicht deklarativere Scope-Prüfungen in API Gateway. |
| Post-Confirmation-Trigger | Verschiebt bestätigte Benutzer in die Gruppe Registered | Nur echte Registrierungsbestätigungen behandeln, nicht jedes Bestätigungsereignis | Trennt „authentifiziert“ von „ausreichend registriert für API-Aufrufe“. |
| Outputs | Stellt Identitätsartefakte für andere Stacks und Plugins bereit | Pool-IDs, Client-IDs, Domain, Rollen, Gruppen und Funktions-ARNs ausgeben | Outputs sind der Vertrag zwischen diesem Stack und der übrigen Plattform. |
Token- und Autorisierungsmodell
Cognito stellt mehrere Identitätsartefakte bereit, die unterschiedliche Aufgaben haben. Diese Tabelle trennt Browser-Authentifizierung, Gruppen, Scopes, temporäre AWS-Zugangsdaten und dienstseitige Autorisierung.
| Schicht | Artefakt | Was es nachweist | Was es nicht tun sollte |
|---|---|---|---|
| Gatey / Browser | Cognito-Tokens und lokaler Authentifizierungsstatus | Der Benutzer hat den konfigurierten Cognito-Ablauf abgeschlossen | Geheimnisse auf dem WordPress-Server speichern oder Passwörter über PHP weiterleiten. |
| User-Pool-Gruppen | registered, admin oder projektspezifische Gruppen | Der Benutzer gehört zu einer Geschäftsrolle | Der einzige Laufzeit-Durchsetzungspunkt sein. |
| Access-Token-Scopes | sc.group.<group> | Das Token enthält einen von APIs lesbaren Rollenkontext | Backend-Autorisierung ersetzen, wenn Ressourceneigentum relevant ist. |
| Identity-Pool-Rolle | AuthenticatedRole oder RegisteredRole | Der Browser kann temporäre AWS-Zugangsdaten für erlaubte Aktionen erhalten | Breite Berechtigungen auf Kontoebene gewähren. |
| API-Gateway-Methode | Cognito-Scope oder IAM-Autorisierung | Die Route erzwingt Identität an der Dienstgrenze | Sich auf ausgeblendete Schaltflächen oder reine CSS-Beschränkungen verlassen. |
Betriebliche Fehlerfälle
Identitätsfehler wirken oft wie allgemeine Anmeldeprobleme, obwohl E-Mail-Zustellung, Föderation, Token-Scopes oder DNS die Ursache sind. Diese Tabelle ordnet sichtbare Symptome der zu prüfenden Betriebsgrenze zu.
| Fehlerfall | Sichtbares Symptom | Wahrscheinliche Ursache | Runbook-Richtung |
|---|---|---|---|
| reCAPTCHA lehnt Registrierung ab | Benutzer kann kein Konto erstellen | Falscher Site Key oder Secret, veraltetes Token, niedriger Score oder Action-Abweichung | ClientMetadata-Tokenpfad, SSM-Secret, Score-Schwelle und Lambda-Logs prüfen. |
| Benutzerdefinierte E-Mail wird nicht zugestellt | Bestätigungs- oder Passwort-E-Mail fehlt | SES-Identität nicht verifiziert, Sandbox-Einschränkung, Vorlagenlesefehler oder FROM-Abweichung | SES-Identität, CloudWatch-Logs, S3-Vorlagenschlüssel und Fallback prüfen. |
| Soziale Anmeldung erzeugt doppelte Benutzer | Dieselbe E-Mail erscheint unter getrennten Provider-Identitäten | Verknüpfung externer IdPs deaktiviert oder fehlgeschlagen | Pre-Sign-Up-Logs und AdminLinkProviderForUser-Berechtigungen prüfen. |
| API-Aufruf nach Anmeldung abgelehnt | Frontend authentifiziert, API antwortet mit 401/403 | Benutzer nicht in Registered, Scopes fehlen, Identity-Pool-Rolle nicht zugeordnet oder Authorizer fehlerhaft | Token-Scopes, Gruppenmitgliedschaft, Post-Confirmation-Logs und API-Gateway-Authorizer prüfen. |
| Benutzerdefinierte Domain funktioniert nicht | Hosted UI oder Callback-Domain wird nicht aufgelöst | Zertifikatsregion oder -validierung, Route53-Zonenabweichung oder Aliasziel | ACM-Zertifikat, DNS-Zoneneigentum und Cognito-Domainstatus prüfen. |
Umsetzungspfad
Bauen Sie Identität um die Anwendungsgrenze, nicht um eine WordPress-Sitzung
Die relevante Arbeit für den laufenden Betrieb beginnt nach dem Anlegen des User Pools: Föderation, Lebenszyklus, Autorisierung und wiederholbare Konfiguration.
- Definieren Sie den Eigentümer der Identität — Konzentrieren Sie WordPress auf Inhalt und Darstellung. Nutzen Sie Cognito, wenn dieselbe Besucheridentität auf statische Seiten, APIs oder andere Anwendungsoberflächen ausgedehnt werden muss.
- Konfigurieren Sie die erforderlichen Anmelde- und Föderationspfade — Aktivieren Sie über Cognito und Gatey nur die tatsächlich benötigten Abläufe für Anmeldung, Registrierung, MFA, Profil, soziale Anbieter sowie SAML oder OIDC.
- Ordnen Sie Identität Laufzeitberechtigungen zu — Verwenden Sie Token-Claims, Scopes, Gruppen oder optionale IAM-Zugangsdaten, damit Backend-Dienste Aktionen unabhängig von der Sichtbarkeit im Frontend autorisieren.
- Testen Sie Lebenszyklus und Fehlerzustände — Prüfen Sie Bestätigung, Passwortwiederherstellung, MFA, Provider-Anmeldung, geänderte Gruppenmitgliedschaft, Token-Ablauf und API-Ablehnung getrennt vom Seitenrendering.
Wann Cognito die Anwendungsidentität besitzen sollte
Gute Wahl
Die Identität muss über WordPress hinausreichen
- Dieselben Benutzer benötigen eine Anmeldung auf einem statischen Frontend oder auf Seiten, bei denen WordPress-PHP die Anfrage nicht bedient.
- Die Frontend-Identität muss APIs, geschützte Ressourcen oder andere Anwendungsoberflächen autorisieren.
- Die Organisation hat bereits Anforderungen an soziale, SAML- oder OIDC-Föderation oder erwartet sie.
WordPress-native Authentifizierung behalten
WordPress-Sitzungen können einfacher sein, wenn
- nur wp-admin oder gewöhnliche dynamische WordPress-Seiten authentifizierte Benutzer benötigen.
- keine externe Anwendung, geschützte API oder statische Oberfläche dieselbe Identität benötigt.
- bestehende Plugins direkt vom WordPress-Benutzer- und Sitzungsverhalten abhängen und kein geschäftlicher Grund für ein separates Identitätssubsystem besteht.
Problemleitfäden
Identitätsentscheidungen, die diese Architektur unterstützt
Wann sollte Amazon Cognito WordPress als Anwendungsidentitätsschicht ersetzen?
Siehe Amazon Cognito statt WordPress als Anwendungsidentitätsschicht. WordPress bleibt das CMS, während Cognito die Besucheridentität für die breitere Anwendung besitzt.
Wie verbinde ich vorhandene SAML- oder OIDC-Identitätsanbieter?
Siehe WordPress mit vorhandenen SAML- und OIDC-Anbietern verbinden. Cognito dient als Föderationszentrale, während Gatey eine einheitliche Frontend-Anmeldung bereitstellt.
Wie funktioniert dies auf statischem WordPress?
Siehe Anmeldung zu statischem WordPress hinzufügen, ohne PHP-Sitzungen zurückzubringen. Die Cognito-Anmeldung im Browser übersteht die statische Veröffentlichung, da sie nicht von einer WordPress-PHP-Sitzung abhängt.
Wie unterscheiden sich geschützte statische Dateien von geschützten APIs?
Für statische Auslieferung siehe Statisches WordPress mit CloudFront Signed Cookies schützen. APIs sollten JWT, IAM oder einen anderen unterstützten Autorisierungsmechanismus selbst validieren.
Beginnen Sie mit der Identitätsentscheidung
Nutzen Sie Cognito, wenn Besucheridentität länger als eine WordPress-Anfrage bestehen muss
Wählen Sie den Leitfaden zur Anwendungsidentität für die Grundentscheidung oder den SSO-Leitfaden, wenn die Föderation mit vorhandenen Identitätsanbietern im Mittelpunkt steht.