Suchergebnisse :

×
Jetzt registrieren Kontakt
[smartslider3 Schieberegler = 177]

 Wie richte ich Single Sign On bei WordPress mit Ihrer benutzerdefinierten App/Ihrem benutzerdefinierten IDP ein?


Mit unserem OAuth/OpenID Connect Single Sign On-Plugin können Sie Single Sign-On bei Ihrem benutzerdefinierten Identitätsanbieter einrichten. Wenn Sie möchten, dass sich Ihre Benutzer mit Ihren Identitätsanbieter-Anmeldeinformationen bei Ihrer WordPress-Site anmelden, ist dies mit unserem Plugin möglich. Sie können Benutzern eine SSO-Verbindung zur WordPress-Site herstellen, indem Sie die Anmeldeinformationen Ihres benutzerdefinierten Anbieters verwenden. Ebenso können Sie Ihre WordPress-Rollen basierend auf Ihren benutzerdefinierten Anbieterattributen/-gruppen zuordnen. Um mehr über andere Funktionen zu erfahren, die wir im WP OAuth Client-Plugin bereitstellen, können Sie hier klicken hier klicken.

  • Wenn Ihre Anwendung das Standard-OAuth 2.0-Protokoll unterstützt, wählen Sie in der Anwendungsliste die Option „Benutzerdefinierte OAuth 2.0-App“ aus
  • Wenn Ihre Anwendung das Standard-OpenID-Connect-Protokoll unterstützt, wählen Sie in der Anwendungsliste die Option „Benutzerdefinierte OpenID-Connect-App“ aus

Wenn Ihre App den Standard-OAuth/OIDC-Flow nicht unterstützt, wenden Sie sich bitte an uns oauthsupport@xecurify.com Und wir können eine maßgeschneiderte Lösung für Ihren Anwendungsfall bereitstellen.

 Was ist Single Sign On?


  • Single Sign On ist ein Schema, das es Benutzern ermöglicht, sich mit einem einzigen Satz an Anmeldeinformationen, d. h. Benutzername und Passwort, bei mehreren Anwendungen anzumelden.
  • Vereinfacht ausgedrückt bedeutet Single Sign-On (SSO), dass Sie sich bei einer Site/Anwendung mit den Anmeldeinformationen einer anderen App/Site anmelden.
  • Beispiel: Wenn Sie alle Ihre Benutzer/Kunden/Mitglieder/Mitarbeiter auf einer Website gespeichert haben (z. B. Gmail, WordPress usw.), sagen wir Website A, und Sie möchten, dass sich alle auf Ihrer WordPress-Website registrieren/anmelden, beispielsweise Website B . In diesem Szenario können Sie alle Ihre Benutzer von Site A bei Site B mit den Anmeldeinformationen/Konto von Site A registrieren/anmelden. Dies wird als Single Sign-On oder SSO bezeichnet.
SSO

 Was ist OAuth?


  • OAuth (Open Authorization) ist ein offener Standard für tokenbasierte Authentifizierung und Autorisierung, der zur Bereitstellung von Single Sign-On (SSO) verwendet wird.
  • OAuth ermöglicht die Nutzung der Kontoinformationen eines Endbenutzers durch Drittanbieterdienste wie Facebook, ohne dass das Passwort des Benutzers preisgegeben wird.
  • Es fungiert als Vermittler im Namen des Endbenutzers und stellt dem Dienst ein Zugriffstoken zur Verfügung, das die Weitergabe bestimmter Kontoinformationen autorisiert.
SSO

 Standard-OAuth 2.0-Ablauf


    Der Client sendet die Autorisierungsanfrage mit einer Reihe von Abfrageparametern über den Browser, die zum Autorisierungsendpunkt auf dem Autorisierungsserver umleiten. So sieht eine Musteranfrage aus

    Standard OAuth 2.0 Request:
GET <authorization-endpoint>?
       response_type=code
       &client_id=<client_id>
       &redirect_uri=<callback_url>
       &scope=openid&state=<security_token>

    • OAuth 2.0-Endpunkte
        • 1. Autorisierungsendpunkt: Der Autorisierungsendpunkt ist der Endpunkt auf dem Autorisierungsserver, an dem sich der Ressourceneigentümer anmeldet und der Clientanwendung Autorisierung erteilt.
        Request:
GET https://authorization-server.com/oauth/authorize
?client_id=<client_id>
&response_type=<code>
&state=<state>
&redirect_uri=<redirect_uri>
&scope=<scope>

        Response:
HTTP/1.1 302 Found
Location: https://custom-app.com/redirect?code=g0ZGZmNjVmOWI&state=dkZmYxMzE2
        2. Token-Endpunkt: Der Token-Endpunkt ist der Endpunkt auf dem Autorisierungsserver, an dem die Clientanwendung den Autorisierungscode, die Client-ID und das Client-Geheimnis gegen ein Zugriffstoken austauscht.
        Request:
GET https://authorization-server.com/oauth/token
grant_type=<grant_type>
&code=<code>
&redirect_uri=<redirect_uri>

        Response:
HTTP/1.1 200 OK
Content-Type: application/json
 
{
  "access_token":"MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3",
  "token_type":"bearer",
  "expires_in":3600,
  "refresh_token":"IwOGYzYTlmM2YxOTQ5MGE3YmNmMDFkNTVk",
  "scope":"create"
}
        3. Benutzerinfo-Endpunkt: Der Userinfo-Endpunkt gibt Ansprüche über den authentifizierten Endbenutzer zurück.
        Request:
GET https://authorization-server.com/oauth/v1/userinfo
Header:
Authorization : Bearer < access_token / id_token >

        Response:
HTTP/1.1 200 OK
Content-Type: application/json

{
 "sub"         : "248289761001",
 "name"        : "testuser"
 "given_name"  : "testuser",
 "email"       : "testuser@custom-app.com",
}
    • Von unserem Plugin für benutzerdefinierte Anbieter unterstützte Förderarten
        • 1. Autorisierungscode-Gewährung
        2. Implizite Gewährung
        3. Token-Zuteilung aktualisieren
        4. Gewährung von Anmeldeinformationen für Ressourceneigentümer
        5. Gewährung von Kundenanmeldeinformationen

    • Unterschied zwischen Standard- und benutzerdefinierten OAuth-Anbietern
      • Standard-OAuth-Anfrage Benutzerdefinierte OAuth-Anfrage 
      Standard OAuth 2.0 Request:
GET <authorization-endpoint>?
       response_type=code
       &client_id=<client_id>
       &redirect_uri=<callback_url>
       &scope=openid

      Custom OAuth 2.0 Request:
GET <authorization-endpoint>?
       response_type=code
       &client_id=<client_id>
    • Für verschiedene Anbieter gelten unterschiedliche Anforderungen
      • Zum Beispiel: Bei einigen Anbietern ist der Bereichsparameter nicht erforderlich. Einige Anbieter erfordern Client-Anmeldeinformationen nur im Header, während andere sowohl im Header als auch im Hauptteil verlangen. Einige Anbieter senden JWT-Token unter dem Zugriffstoken-Parameter. Alle diese Fälle werden in unserem Plugin behandelt
Hallo!

Brauchen Sie Hilfe? Wir sind hier!

Unterstützung