Vergleich · WordPress-Identitätsarchitektur
Gatey vs. WordPress-SSO-Plugins
Ein praktischer Vergleich für Teams, die entscheiden, ob WordPress das Identitätssystem bleiben, ein allgemeines SSO-Plugin verwenden oder Amazon Cognito als Identitätsschicht hinter WordPress und statischen Frontends dienen soll.
Kurzfassung Ein traditionelles WordPress-SSO-Plugin kann richtig sein, wenn die gesamte Umgebung dynamisches WordPress bleibt und lediglich die Anmeldung bei WordPress erforderlich ist. Gatey ist für Projekte gedacht, in denen Identität auch außerhalb von PHP funktionieren muss: statische Exporte, Cognito-basierte Social-/SAML-/OIDC-Föderation, Frontend-Kontofunktionen, JWT/IAM-geschützte APIs und AWS-native Laufzeitdienste.
Warum das wichtig ist
SSO ist mehr als eine Funktion der Anmeldeseite.
Für viele Intranets, Mitgliederseiten und dynamische WordPress-Portale genügt es, einen Identitätsanbieter einzurichten und Attribute WordPress-Benutzern zuzuordnen. Die Architekturfrage ändert sich, sobald WordPress nicht mehr die einzige Laufzeit ist.
Entscheidung 01
Nur Anmeldung bei WordPress oder gemeinsames Identitätsfundament?
Ein typisches SSO-Plugin meldet Benutzer über einen externen IdP bei WordPress an. Gatey macht Cognito-Identität dagegen über WordPress, statische Seiten und AWS-APIs hinweg nutzbar.
Entscheidung 02
Wo liegen Benutzer, Föderation und Tokens?
Im Gatey-Modell liegen Benutzer, Gruppen, MFA, Social-/SAML-/OIDC-Föderation und Tokens in Cognito. WordPress speichert Konfiguration und rendert die Oberfläche, statt als primäre Identitätsdatenbank zu dienen.
Entscheidung 03
Muss Identität den statischen Export überdauern?
Ein statisches Frontend kann nicht für jede Interaktion von wp-login.php abhängen, und für eine Browseranwendung mit API Gateway ist ein PHP-Session-Cookie kein geeignetes primäres Autorisierungsmodell. Cognito-Tokens funktionieren auf statischen Seiten, hinter CloudFront und in nachgelagerten APIs.
Folgerung Entscheidend ist, ob nur SSO in WordPress oder ein Identitätsfundament benötigt wird, an dem WordPress teilnimmt und dessen Anmeldestatus auch in statischen Frontends und AWS-Diensten gilt.
Entscheidungstabelle
Drei Kriterien unterscheiden Gatey von typischen WordPress-SSO-Plugins
Gatey löst eine breitere Architekturaufgabe; ein allgemeines SSO-Plugin kann einfacher sein, wenn nur WordPress-Anmeldung erforderlich ist.
| Entscheidungskriterium | Gatey | Typisches WordPress-SSO-Plugin |
|---|---|---|
| Primäres Ziel und Laufzeit | Der Browser kommuniziert direkt mit Cognito, sodass Identität in WordPress, auf statischen Seiten und in AWS-APIs verwendet werden kann. | Meldet Benutzer über einen externen IdP bei WordPress an und hängt häufig vom WordPress-/PHP-Session-Ablauf ab. |
| Föderation und API-Zugriff | Amazon Cognito verwaltet Social-, SAML- und OIDC-Anbieter. Dieselbe Schicht kann API-Gateway- und Lambda-Endpunkte durch JWT-Prüfung oder Cognito-Identity-Pool-/IAM-Muster schützen. | Das Plugin ordnet gewöhnlich einen Identitätsanbieter WordPress-Benutzern zu. Die Autorisierung separater AWS-APIs ist meist nicht sein Hauptanliegen. |
| Statisches Frontend und beste Eignung | Für statische Portale, AWS-gestütztes WordPress, geschützte CloudFront-Inhalte, Kundenportale und ein gemeinsames Identitätsfundament. | Für klassisches dynamisches WordPress-SSO, wenn wp-admin/wp-login-Integration die Hauptanforderung ist und die Sitzung keine separaten AWS-Laufzeiten autorisieren muss. |
Wann passt welcher Ansatz?
Gatey passt besser
Wählen Sie Gatey, wenn der Identitätsstatus über WordPress hinaus gültig sein muss.
- Ein statisches WordPress-Frontend benötigt weiterhin Anmeldung, Registrierung, Passwortzurücksetzung, MFA oder Profilbearbeitung.
- Frontend-Komponenten rufen AWS-APIs auf und benötigen JWT- oder IAM-Autorisierung; die Identität muss auch für CloudFront, API Gateway, Lambda, KI- oder Workflow-Dienste funktionieren.
- Der Kunde möchte Identität, Gruppen und Benutzerlebenszyklus im eigenen AWS-Konto halten, während die Agentur dasselbe Muster über WordPress-, statische und serverlose Projekte wiederverwendet.
Das allgemeine SSO-Plugin passt besser
Wählen Sie ein traditionelles SSO-Plugin, wenn WordPress die vollständige Anwendung bleibt.
- Es wird nur SSO für wp-admin oder eine klassische dynamische WordPress-Mitgliederseite benötigt.
- Das Team möchte keine AWS-Infrastruktur besitzen oder konfigurieren und erwartet, dass das Plugin die gesamte Identitätsinfrastruktur verbirgt.
- Statische Kompatibilität, API-Autorisierung und Cognito-Föderation sind nicht erforderlich, oder der Kunde hat bereits einen Managed Identity SaaS mit WordPress-Connector vorgegeben.
Vergleichs-FAQ
Häufige Fragen beim Vergleich von Gatey und WordPress-SSO-Plugins
Ist Gatey nur ein SSO-Plugin?
Nein. Es unterstützt SSO-Anwendungsfälle, doch das umfassendere Muster ist Cognito-gestützte Identität für WordPress, statische Frontends und AWS-APIs.
Kann ein normales WordPress-SSO-Plugin einfacher sein?
Ja. Wenn Benutzer lediglich bei einer dynamischen WordPress-Website angemeldet werden sollen, kann ein traditionelles SSO-Plugin einfacher sein.
Speichert Gatey Cognito-Client-Secrets in WordPress?
Der empfohlene browserbasierte Cognito-Ablauf verwendet einen öffentlichen App-Client ohne Client-Secret. Sensibler Identitätsstatus sollte in Cognito und in der Browser-Sitzung bleiben, nicht in WordPress-Optionen.
Funktioniert das nach statischem Export, und wie hilft es bei APIs?
Ja. Das Frontend kann direkt mit Cognito kommunizieren, wenn exportierte Assets und Callback-URLs korrekt konfiguriert sind. Von Cognito ausgestellte Tokens oder IAM-Anmeldedaten können API Gateway und Lambda ohne WordPress-Proxy prüfen.
Wählen Sie die richtige Identitätsschicht für WordPress
Vergleichen Sie reines WordPress-SSO mit einem Cognito-orientierten Modell.
Entscheiden Sie danach, wo Identität gültig sein muss: nur im dynamischen WordPress oder auch in statischen Frontends, Kontofunktionen und AWS-APIs.