Identitätsentscheidung für WordPress
Amazon Cognito vs. WordPress-native Authentifizierung
Die eigentliche Entscheidung betrifft nicht das Aussehen des Anmeldeformulars. Entscheidend ist, ob die Besucheridentität zur WordPress-Anwendung gehört oder über statische Seiten, föderierte Anbieter und geschützte APIs hinweg nutzbar bleiben muss.
Kurzurteil Verwenden Sie die WordPress-native Authentifizierung, wenn WordPress selbst die Anwendungsgrenze bildet. Wählen Sie Cognito mit Gatey, wenn die Anwendungsidentität die statische Veröffentlichung überdauern, soziale oder SAML/OIDC-Anbieter föderieren oder APIs außerhalb von WordPress autorisieren muss.
Die Entscheidung
Legen Sie fest, wo die Identität maßgeblich bleibt
Anmeldung, Kontostatus und API-Autorisierung werden schwer nachvollziehbar, wenn sie ohne bewusst gesetzte Identitätsgrenze auf mehrere Systeme verteilt sind.
Laufzeit
WordPress-Sitzungen setzen voraus, dass WordPress die Anfrage verarbeitet
Das ist für dynamisches WordPress selbstverständlich, passt aber nicht zu einem öffentlich statisch ausgelieferten Frontend, das bei Seitenaufrufen kein PHP mehr aufruft.
Föderation
Externe Identitätsanbieter erweitern die Anwendungsgrenze
Soziale Anbieter und benutzerdefinierte SAML/OIDC-Föderation lassen sich leichter als gemeinsame Anwendungsidentität behandeln, wenn Cognito als Zentrale dient, statt für jede Website-Oberfläche eigene Anmeldelogik einzubauen.
Autorisierung
Eine Website-Sitzung ist nicht dasselbe wie API-Autorisierung
Geschützte APIs benötigen Token, IAM oder einen anderen vom Backend durchgesetzten Mechanismus, der unabhängig von sichtbaren WordPress-Rollen oder Schaltflächen geprüft werden kann.
Folge für die Entscheidung Behalten Sie WordPress-native Benutzer bei, wenn WordPress die Anwendungsgrenze bildet. Verlagern Sie Besucheridentitäten zu Cognito, wenn dieselbe Identität Frontend-, API- oder Föderationsgrenzen überschreiten muss.
Direktvergleich
Vergleichen Sie die Betriebsmodelle für Identitäten
Beide Modelle sind valide. Welches besser passt, hängt davon ab, wo der Authentifizierungsstatus nach der Anmeldung weiter nutzbar sein muss.
| Entscheidungskriterium | Amazon Cognito + Gatey | WordPress-native Authentifizierung |
|---|---|---|
| Frontend-Laufzeit | Gatey authentifiziert im Browser gegen Cognito. Unterstützte Abläufe für Anmeldung, Registrierung, MFA, Passwortzurücksetzung und Profil können daher auch nach einem statischen Export weiter funktionieren. | Native Benutzer und Sitzungen passen zu einer laufenden WordPress-Umgebung, in der PHP und die WordPress-Datenbank für authentifizierte Anfragen verfügbar bleiben. |
| Föderation und APIs | Cognito kann soziale sowie benutzerdefinierte SAML/OIDC-Anbieter föderieren. Gatey kann die daraus entstehende Identität für JWT- oder IAM-autorisierte API-Zugriffe verwenden. | WordPress-Plugins können SSO- und API-Muster ergänzen. Ohne zusätzliche Architektur bleibt das native Benutzer- und Sitzungsmodell jedoch auf WordPress ausgerichtet. |
| Betriebliche Eignung | Geeignet, wenn Identität ein von statischen Seiten, APIs oder mehreren Oberflächen geteilter Anwendungsdienst ist und das Team den Betrieb von Cognito übernimmt. | Geeignet, wenn WordPress selbst die Anwendung ist und vorhandene Plugins native Benutzer, Rollen und Sitzungen voraussetzen. |
Welches Identitätsmodell passt zum Projekt?
Cognito + Gatey wählen
Wenn Identität über WordPress hinausreicht
- Das öffentliche Frontend kann statisch sein, während Besucher weiterhin Anmeldung, Registrierung, MFA oder Profilfunktionen benötigen.
- Dieselben Benutzer müssen geschützte APIs aufrufen oder sich über soziale, SAML- oder OIDC-Anbieter föderieren.
- WordPress soll CMS und Darstellungsschicht bleiben, nicht die Identitätsdatenbank der Anwendung.
WordPress-native Authentifizierung wählen
Wenn WordPress bereits die richtige Identitätsgrenze ist
- Die Website bleibt eine konventionelle dynamische WordPress-Anwendung.
- Mitgliedschafts- oder Plugin-Funktionen hängen direkt von WordPress-Benutzer-IDs, Rollen und Sitzungen ab.
- Es besteht kein Bedarf an einem separaten Identitätsdienst, einer Anmeldung am statischen Frontend oder einer anwendungsübergreifenden API-Identität.
Problemorientierte Leitfäden
Gehen Sie vom Identitätsproblem aus weiter
Wann sollte Cognito zur Identitätsschicht der Anwendung werden?
Beginnen Sie mit Amazon Cognito anstelle von WordPress als Identitätsschicht der Anwendung verwenden und nutzen Sie anschließend Cognito Day-2-Identitätsarchitektur für WordPress für die Umsetzungsgrenze.
Wie füge ich einer statischen WordPress-Website eine Anmeldung ohne PHP-Sitzungen hinzu?
Lesen Sie Anmeldung zu statischem WordPress hinzufügen, ohne PHP-Sitzungen zurückzubringen. Gatey führt unterstützte Authentifizierungsabläufe im Browser gegen Cognito aus, sodass die öffentliche Seite keine WordPress-Sitzung benötigt.
Wie binde ich vorhandene SAML- oder OIDC-Identitätsanbieter an?
Nutzen Sie WordPress mit vorhandenen SAML- und OIDC-Identitätsanbietern verbinden, ohne separate Anmeldeabläufe zu entwickeln. Benutzerdefinierte SAML/OIDC-Anbieter sind eine über Cognito konfigurierte Gatey-Pro-Funktion.
Autorisiert eine erfolgreiche Anmeldung automatisch APIs oder geschützte Dateien?
Nein. Geschützte APIs müssen JWT, IAM oder einen anderen geeigneten Backend-Autorisierungsmechanismus prüfen. Geschützte statische Pfade besitzen eine separate CloudFront-Zugriffsgrenze.
Zuerst die Identitätsgrenze festlegen
Verwenden Sie Cognito, wenn Identität außerhalb der WordPress-Sitzung nutzbar bleiben muss
Beginnen Sie mit dem Problem der Anwendungsidentität. Nutzen Sie den Leitfaden zur statischen Anmeldung, wenn PHP-Sitzungen unmittelbar aus dem öffentlichen Frontend entfernt werden sollen.