Zu Hauptinhalt springen Zu ergänzendem Inhalt springen

OpenID Connect zur Integration in Identitätsanbieter

OpenID Connect (OIDC) wird für die Integration von Qlik Cloud in Identitätsanbieter verwendet. OIDC ist eine dünne Identitätsebene oberhalb des OAuth 2.0-Protokolls. OAuth 2.0 ist das Standardprotokoll für die Autorisierung und OIDC das Standardprotokoll für die Authentifizierung von Benutzern. Zusammen gewähren die beiden Protokolle sicheren Zugriff auf zahlreiche Apps und Websites über Single Sign-On (SSO), ohne dass Sie sich mehrmals anmelden müssen.

OAuth 2.0 ist nur für die Autorisierung konzipiert. Sie können Zugriff auf Daten und Funktionen von einer Anwendung zu einer anderen gewähren, indem Sie dem anfordernden Client einen Schlüssel bereitstellen. Da ein Schlüssel verwendet wird, geben Sie nicht Ihre Anmeldedaten weiter. Stattdessen verwenden Sie Ihre Anmeldedaten bei einer Anwendung, bei der Sie bereits ein registrierter Benutzer sind, z. B. bei einem E-Mail-Anbieter. Der Schlüssel stellt sicher, dass Sie nur Informationen weitergeben, deren Weitergabe Sie bereits zugestimmt haben. Sie sind auch berechtigt, den Schlüssel jederzeit zurückzuziehen.

Der Schlüssel ist nützlich, gibt aber keine Informationen über Sie als Benutzer bekannt. OIDC fügt Funktionen zur Anmeldung und Profilinformationen zur angemeldeten Person hinzu, indem ID-Token verwendet werden. OIDC ermöglicht verschiedenen Clients (webbasierten, mobilen, Javascript- und anderen Clients) das Überprüfen der Identität des Benutzers, gestützt auf die von einem Autorisierungsserver durchgeführte Authentifizierung. Clients können auch grundlegende Profilinformationen des Benutzers anfordern.

Eine Einführung in OAuth und OpenID Connect finden Sie in folgendem Video: An Illustrated Guide to OAuth and OpenID Connect.

ID-Token

OpenID Connect verwendet ID-Token, welche die Integration vereinfachen und eine Vielzahl verschiedener Apps unterstützen.

Ein ID-Token ist eine besonders formatierte Zeichenfolge, die als JSON Web Token oder JWT bekannt ist. JWTs sind vielseitig und unterstützen verschiedene Signaturen und Verschlüsselungsalgorithmen. Clients können in das JWT eingebettete Informationen extrahieren, beispielsweise die ID, den Namen, die Anmeldeuhrzeit, den Ablauf des ID-Tokens und ob Versuche unternommen wurden, das JWT zu manipulieren. Die innerhalb des ID-Tokens enthaltenen Datenelemente werden als Ansprüche bezeichnet.

Wie bereits erwähnt, verwenden Clients OAuth 2.0-Abläufe, um ID-Token zu erhalten, die sowohl mit Web-Apps als auch mit nativen Mobil-Apps funktionieren.

Zugriffs-Token

Neben den ID-Token gibt es Zugriffs-Token. Das sind Anmeldedaten, die von einer Anwendung für den Zugriff auf eine API verwendet werden können. Ein Zugriffs-Token kann ein JWT-Token oder ein anderes Token sein. Anhand des Tokens wird die API informiert, dass dem Überbringer des Tokens Zugriff auf die API gewährt wurde.

Ansprüche

JWT-Token enthalten Ansprüche. Dies sind Aussagen (z. B. Name oder E-Mail-Adresse) zu einem Element (in der Regel ein Benutzer) sowie zusätzliche Metadaten.

Die OIDC-Spezifikation definiert eine Reihe von Standardansprüchen. Zu den Standardansprüchen zählen Name, E-Mail, Geschlecht, Geburtsdatum und andere Werte. Wenn Sie Informationen zu einem Benutzer erfassen möchten, für den kein Standardanspruch vorliegt, können Sie benutzerdefinierte Ansprüche erstellen und sie zu Ihren Token hinzufügen.

OpenID Connect-Spezifikation

Die OpenID Connect 1.0-Spezifikation setzt sich aus folgenden Dokumenten zusammen. Qlik unterstützt diese Spezifikation, aber nicht alle spezifischen benutzerdefinierten Anbieterimplementierungen der Spezifikation. Qlik kann entscheiden, als Erleichterung für unsere Kunden Konfigurationen für beliebte Identitätsmanagementprodukte und -plattformen hinzuzufügen.

  • Core: Definiert die OpenID Connect-Kernfunktionen: Authentifizierung gestützt auf OAuth 2.0 mit Nutzung von Ansprüchen, um Informationen zum Benutzer mitzuteilen
  • Discovery (optional): Definiert, wie Clients dynamisch Informationen über OpenID-Anbieter erkennen
  • Dynamic Registration (optional): Definiert, wie sich Clients dynamisch bei OpenID-Anbietern registrieren
  • OAuth 2.0 Multiple Response Types: Definiert spezifische neue OAuth 2.0-Antworttypen
  • OAuth 2.0 Form Post Response Mode (optional): Definiert, wie OAuth 2.0-Autorisierungsantwortparameter (einschließlich OpenID Connect-Authorisierungsantwortparametern) anhand von HTML-Formularwerten zurückgegeben werden, die automatisch vom Benutzer-Agent mit HTTP POST gesendet werden
  • Session Management (optional): Definiert, wie OpenID Connect-Sitzungen verwaltet werden, darunter postMessage-basierte Abmeldung und RP-initiierte Abmeldung
  • Front-Channel Logout (optional): Definiert einen Front-Channel-Abmeldemechanismus, der keinen OP-iFrame auf RP-Seiten verwendet
  • Back-Channel Logout (optional): Definiert einen Abmeldemechanismus, der direkte Back-Channel-Kommunikation zwischen dem OP und den abgemeldeten RPs verwendet
  • OpenID Connect Federation (optional): Definiert, wie Sätze von OPs und RPs über einen Verbundoperator eine vertrauenswürdige Beziehung festlegen können

Um auf die Dokumente zuzugreifen, gehen Sie zu Willkommen bei OpenID Connect.

Hat diese Seite Ihnen geholfen?

Wenn Sie Probleme mit dieser Seite oder ihren Inhalten feststellen – einen Tippfehler, einen fehlenden Schritt oder einen technischen Fehler –, teilen Sie uns bitte mit, wie wir uns verbessern können!