Gatey + Amazon Cognito
Amazon Cognito statt WordPress als Identitätsschicht der Anwendung verwenden
WordPress kann CMS und Präsentationsschicht bleiben, während Amazon Cognito die Frontend-Anwendungsidentität, den Kontolebenszyklus, MFA, Föderation und die Token für geschützte APIs verwaltet.
Kurz gesagt Nutzen Sie Gatey, um Cognito-gestützte Authentifizierung in WordPress darzustellen. Der Browser authentifiziert sich bei Ihrem Cognito User Pool, während WordPress für Inhalt und Layout verantwortlich bleibt, statt als Identitätsspeicher der Anwendung zu dienen.
Warum Identität getrennt werden sollte
CMS-Benutzer und Anwendungsbenutzer gehören nicht immer in dieselbe Laufzeit
WordPress-Benutzerkonten eignen sich für Redakteure und einfache Mitgliedschaftsfunktionen. Anwendungsidentität wird zu einer anderen Aufgabe, wenn dieselben Benutzer sich bei APIs, statischen Frontends, SSO-Anbietern oder anderen AWS-Diensten authentifizieren müssen.
Laufzeitkopplung
WordPress-Authentifizierung setzt eine WordPress-Sitzung voraus
Eine PHP-Sitzung ist auf einer dynamischen WordPress-Website praktisch, wird aber zur Einschränkung, wenn das Frontend statisch ist oder dieselbe Identität außerhalb von WordPress funktionieren muss.
Föderation
Unternehmens- und Social-Login sollten keine getrennte WordPress-Anmeldelogik erfordern
Cognito kann als Identitätszentrale für native Benutzer, soziale Anbieter und konfigurierte SAML- oder OIDC-Anbieter dienen, während Gatey die daraus entstehende Frontend-Oberfläche bereitstellt.
APIs
Geschützte Anwendungsaktionen benötigen ein übertragbares Identitäts-Token
Formulare, Kontofunktionen, Workflows und andere APIs müssen den Aufrufer unabhängig autorisieren. Cognito-JWTs oder IAM-basierter Zugriff schaffen eine Identitätsgrenze, die nicht an WordPress-PHP gebunden ist.
Architekturgrenze WordPress verwaltet redaktionelle Benutzer und Inhalte. Cognito verwaltet die Anwendungsidentität, wenn diese über die CMS-Laufzeit hinausreichen muss.
Identitätsgrenze
WordPress stellt die Oberfläche bereit; Cognito authentifiziert den Anwendungsbenutzer
Gatey verbindet WordPress-Seiten direkt aus dem Browser mit Cognito. Dadurch kann dasselbe Frontend-Identitätsmodell auf dynamischen und statisch exportierten WordPress-Websites funktionieren.
WordPress / Gutenberg
|
v
Gatey Authenticator und Kontooberfläche
|
v
Browser des Besuchers
|
v
Amazon Cognito User Pool
| Anmeldung / Registrierung / MFA / Profil
| Social- / SAML- / OIDC-Föderation
v
JWT / Identitätskontext
|
+--> bedingte Frontend-Oberfläche
+--> API Gateway / geschützte APIs
+--> Identitätsabläufe auf statischen Websites
Autorisierungsgrenze Der Frontend-Identitätsstatus kann die Benutzererfahrung verbessern, doch das Ausblenden eines Blocks ist keine Autorisierung. Jeder geschützte Backend-Endpunkt muss das Token oder die IAM-Identität unabhängig prüfen.
Implementierung
Verlagern Sie die Anwendungsidentität, ohne das CMS zu verlagern
Konfigurieren Sie Cognito als Identitätsquelle und verbinden Sie sie anschließend über Gatey mit dem WordPress-Frontend.
- Erstellen oder wählen Sie den Cognito User Pool — Konfigurieren Sie App Client, Anmeldeverfahren, erforderliche Attribute, MFA und die Identitätsanbieter, die die Anwendung benötigt.
- Verbinden Sie Gatey — Konfigurieren Sie User Pool ID, App Client ID, Region und die Frontend-Authentifizierungsoberfläche in WordPress.
- Entwerfen Sie kontobewusstes Frontend-Verhalten — Platzieren Sie Blöcke für Anmeldung, Registrierung, Profil und Kontoattribute dort, wo sie benötigt werden, und definieren Sie die bedingte Frontend-Darstellung.
- Schützen Sie Anwendungs-APIs separat — Verwenden Sie JWT- oder IAM-Autorisierung für APIs und testen Sie denselben Identitätspfad im produktiven oder statisch exportierten Frontend.
Wann Cognito die Anwendungsidentität verwalten sollte
Gut geeignet
Nutzen Sie Cognito, wenn Identität über WordPress hinausreicht
- Die Website benötigt Frontend-Anmeldung, MFA, Profile oder SSO, die auch nach einem statischen Export funktionieren sollen.
- Dieselben Benutzer müssen geschützte APIs aufrufen oder an AWS-gestützten Anwendungsworkflows teilnehmen.
- WordPress soll auf Inhalte und Darstellung konzentriert bleiben, statt der primäre Identitätsspeicher der Anwendung zu sein.
WordPress-eigene Benutzer beibehalten
WordPress-Benutzer können einfacher sein, wenn
- Nur WordPress selbst Authentifizierung benötigt und die Website vollständig dynamisch bleibt.
- Keine externen Anwendungen, APIs, statischen Frontends oder Anforderungen an Unternehmensföderation bestehen.
- Das Team Amazon Cognito weder konfigurieren noch betreiben möchte.
Fragen von Käufern
FAQ zu Cognito als WordPress-Identitätsschicht
Wie kann ich Amazon Cognito statt WordPress-Benutzern für die Anwendungsauthentifizierung einsetzen?
Nutzen Sie Cognito als Frontend-Identitätsanbieter und Gatey als WordPress-Integrationsschicht. Der Browser authentifiziert sich beim konfigurierten User Pool und kann die resultierende Identität für Kontooberflächen und geschützte API-Aufrufe verwenden.
Funktioniert die Cognito-Anmeldung nach einem statischen WordPress-Export?
Ja. Gatey führt den Authentifizierungsablauf im Browser mit Cognito aus. Das öffentliche Frontend benötigt daher keine WordPress-PHP-Sitzung für die Anmeldung.
Kann Cognito MFA und Unternehmens-SSO bereitstellen?
Ja. Cognito kann MFA anbieten und konfigurierte SAML- oder OIDC-Anbieter föderieren. Gatey stellt diese Frontend-Abläufe entsprechend der Website-Konfiguration und dem Tarif in WordPress bereit.
Verschwinden WordPress-Benutzer durch die Nutzung von Cognito?
Nein. WordPress-Benutzer können für Administratoren und Redakteure bestehen bleiben. Die Architektur trennt redaktionelle Identität von der Frontend-Anwendungsidentität, wenn diese Aufgaben unterschiedliche Laufzeiten benötigen.
WP Suite Gatey
Behalten Sie WordPress als CMS und verlagern Sie die Anwendungsidentität zu Cognito
Verbinden Sie WordPress-Seiten mit Gatey und Amazon Cognito für Frontend-Authentifizierung, MFA, SSO und geschützten API-Zugriff.