SAML2 vs JWT: Grundlegendes zu OpenID Connect Teil 1

Dieser Beitrag baut auf dem auf, was wir in früheren Beiträgen über OAuth2 und JWT gelernt haben. OpenID Connect wird uns den letzten Baustein für die JWT-bezogenen Anwendungsfälle geben, die in dieser Serie untersucht werden. Das Ziel dieses Blog-Beitrags ist es, ein tiefes Verständnis der OpenID Connect-Spezifikation zu vermitteln, ohne die Spezifikationen lesen zu müssen.

Geschichte von OpenID

Es gibt drei Generationen der OpenID-Technologie. OpenID Connect (OIDC) ist das dritte - es wurde im November 2014 veröffentlicht. Die ursprüngliche OpenID-Spezifikation (erste Generation) wurde im Mai 2005 von Brad Fitzpatrick veröffentlicht. Es wurde ursprünglich in der Tradition von YACC - Noch ein Compiler Compiler - und YAML - Noch eine andere Auszeichnungssprache - als YADIS (Noch ein anderes verteiltes Identitätssystem) bezeichnet. Die OpenID-Spezifikation der zweiten Generation (OpenID v2.0) wurde im Dezember 2007 veröffentlicht.

Die Spezifikation der ersten Generation wurde nicht allgemein übernommen. Die Spezifikation der zweiten Generation hatte eine viel größere Akzeptanz und Reife. Es gab jedoch Designeinschränkungen, darunter, dass Relying Parties (RPs) Webanwendungen (aber keine nativen Anwendungen) sein konnten und XML verwendeten.

Was ist OpenID Connect?

Von openid.net aus ist „OpenID Connect 1.0 eine einfache Identitätsschicht über dem OAuth 2.0-Protokoll. Es ermöglicht Clients, die Identität des Endbenutzers anhand der von einem Autorisierungsserver durchgeführten Authentifizierung zu überprüfen und grundlegende Profilinformationen über den Endbenutzer auf interoperable und REST-ähnliche Weise abzurufen manner ”macht OIDC eher zu einer API (in Anlehnung an OAuth2) als zu den vorherigen Generationen von OpenID. OIDC erweitert den OAuth2 Authorization Code Grant (dreibeiniges OAuth).

OIDC baut auf den Lehren der frühen OpenID-Protokolle und SAML2 auf, einschließlich:

  • halte die Dinge einfach
  • auf OAuth2 aufbauen
  • benutzerfreundliche Token (JWT) verwenden

OIDC kann mit integrieren

  • traditionelle Webanwendungen
  • mobile Apps
  • Einseitige Anwendungen (SPA-Apps)
  • Server-Anwendungen
  • die meisten anderen Schauspieler

OIDC besteht aus folgenden Spezifikationen (von openid.net):

  • Kern (erforderlich): OIDC-Kernfunktionalität: Auf OAuth 2.0 aufbauende Authentifizierung und Verwendung von Ansprüchen zur Übermittlung von Endbenutzerinformationen.
  • Ermittlung (optional): Wie Clients Informationen zu OpenID-Anbietern (z. B. Autorisierungsservern oder Identitätsanbietern) dynamisch ermitteln.
  • Dynamische Registrierung (optional): Wie Clients sich dynamisch bei OpenID Providers registrieren.
  • Mehrere OAuth 2.0-Antworttypen (erforderlich): Definiert mehrere bestimmte neue OAuth 2.0-Antworttypen.
  • Post-Response-Modus für OAuth 2.0-Formulare (optional): Definiert, wie OAuth 2.0-Autorisierungsantwortparameter (einschließlich der OIDC-Authentifizierungsantwortparameter) unter Verwendung von HTML-Formularwerten zurückgegeben werden, die vom Benutzeragenten mithilfe von HTTP POST automatisch übermittelt werden
  • Sitzungsverwaltung (optional): Legt fest, wie OIDC-Sitzungen verwaltet werden, einschließlich nach der Nachricht abgemeldeter Funktionen
  • Front-Channel-Abmeldung (optional): Definiert einen Front-Channel-Abmeldemechanismus, bei dem auf RP-Seiten kein OP-Iframe verwendet wird
  • Back-Channel-Abmeldung (optional): Definiert einen Abmeldemechanismus, der die Back-Channel-Kommunikation zwischen dem OP und den abgemeldeten RPs verwendet.

Es stehen auch zwei Implementierungshandbücher zur Verfügung, die als Referenz für Implementierer grundlegender webbasierter vertrauender Parteien dienen:

  • Basic Client Implementer's Guide: Einfache Teilmenge der Kernfunktionalität für eine webbasierte vertrauende Partei, die den OAuth-Code-Fluss verwendet
  • Implicit Client-Implementierungshandbuch: Einfache Teilmenge der Kernfunktionalität für eine webbasierte vertrauende Partei, die den OAuth Implicit Flow verwendet

Außerdem ist eine Protokollmigrationsspezifikation verfügbar:

  • OpenID 2.0 zu OpenID Connect Migration 1.0: Definiert, wie von OpenID 2.0 zu OIDC migriert wird

Dieselbe Site basiert auch auf der folgenden Tabelle, in der diese Spezifikationen und die zugehörigen Spezifikationen aufgeführt sind:

Die OIDC-Familie von Spezifikationen und unterstützenden Spezifikationen.

Schauspieler

Die OIDC-Spezifikation definiert mehrere Akteure.

Relying Party (RP): Dies ist ein neuer Begriff, der aus der SAML2-Spezifikation entlehnt wurde. OAuth2-Clientanwendung, die eine Endbenutzerauthentifizierung und Ansprüche von einem OpenID-Anbieter erfordert. Der OpenID-Anbieter (siehe unten) gibt die Authentifizierungsantwort sicher an den OAuth2-Client zurück, damit auf sie vertraut werden kann. Daher wird der Kunde in diesem Zusammenhang als vertrauende Partei bezeichnet.

OpenID Provider (OP): OAuth 2.0-Autorisierungsserver, der in der Lage ist, den Endbenutzer zu authentifizieren und Ansprüche an eine vertrauende Partei bezüglich des Authentifizierungsereignisses und des Endbenutzers zu erheben (gemäß der OIDC-Spezifikation).

Endbenutzer: Dieser Begriff war in OAuth2 vorhanden. Der Principal, der authentifiziert ist (wahrscheinlich ein Mensch).

User Agent: Dieser Begriff war in OAuth2 vorhanden. Etwas, das HTTPS-Anforderungen initiiert und die vom Client und OpenID-Provider generierten Weiterleitungen verarbeiten kann. Dies ist normalerweise ein Benutzeragent oder eine Bibliothek, die die OIDC-Aufrufe verarbeiten kann.

Resource Server: Dieser Begriff war in OAuth2 vorhanden. Der Server, auf dem sich die geschützten Ressourcen befinden und der Anforderungen für geschützte Ressourcen mithilfe von Zugriffstoken annehmen und beantworten kann.

Änderungen am ID-Token (JWT)

Die in der JWT-Spezifikation definierten Ansprüche sind im Beitrag „SAML2 vs. JWT: Grundlegendes zum JSON-Web-Token (JWT)“ beschrieben. Über die Anforderungen der JWT- und JWS-Spezifikationen hinaus erfordert die OIDC-Spezifikation die folgenden Ansprüche in der JWT, die als ID-Token fungieren. Beachten Sie, dass diese Anforderungen nicht unbedingt für ein JWT-Token gelten müssen, das als Zugriffstoken fungiert. Beachten Sie, dass die hier gegebenen Beschreibungen aus der vollständigen Beschreibung der Spezifikation abgeleitet sind.

"Iss" (Issuer) Claim: Kennung für den Identity Provider, der das JWT ausgestellt hat. Dies ist eine URL, bei der die Groß- und Kleinschreibung beachtet wird, wenn das HTTPS-Schema verwendet wird. Dieser Anspruch ist nun erforderlich.

Unteranspruch (Betreff): Betreff-ID. Eine lokal eindeutige und niemals neu zugewiesene Kennung innerhalb des Emittenten für den Endbenutzer, die vom Kunden verwendet werden soll. Dieser Anspruch ist nun erforderlich.

"Aud" (Zielgruppe) Anspruch: Zielgruppe (n), für die dieses ID-Token bestimmt ist. Es muss die OAuth 2.0-client_id der vertrauenden Seite als Zielgruppenwert enthalten. Hierbei kann es sich um eine Reihe von Zeichenfolgen handeln, bei denen zwischen Groß- und Kleinschreibung unterschieden wird. Es kann auch eine einzelne Zeichenfolge enthalten, bei der die Groß- und Kleinschreibung beachtet wird (die oben genannte client_id). Dieser Anspruch ist nun erforderlich.

"Exp" (Expiration) Claim: Zeit, ab der der ID-Token nicht mehr zur Bearbeitung angenommen werden darf. Ein Zeitversatz kann vom Client hinzugefügt werden. Dieser Anspruch ist nun erforderlich.

„Iat“ (Issued At Time) Claim: Zeitpunkt, zu dem das JWT ausgestellt wurde. Dieser Anspruch ist nun erforderlich.

"Auth_time" (Uhrzeit, zu der der Betreff authentifiziert wurde) Behauptung: Uhrzeit, zu der die Endbenutzerauthentifizierung stattgefunden hat. Kann je nach Anwendungsfall erforderlich sein.

"Nonce" (nonce) Claim: String-Wert, der verwendet wird, um eine Client-Sitzung mit einem ID-Token zu verknüpfen und Wiederholungsangriffe abzuschwächen. Kann je nach Anwendungsfall erforderlich sein.

„Acr“ (Authentication Context Class Reference) -Anspruch: Eine Zeichenfolge, die Informationen darüber enthält, wie der Principal authentifiziert wurde. Der Wert „0“ gibt an, dass die Authentifizierung die Anforderungen von ISO / IEC 29115 nicht erfüllt. Diese Angabe ist optional.

„Amr“ (Authentication Methods References) Claim: Ein JSON-Array von Zeichenfolgen, die Identifikatoren für Authentifizierungsmethoden sind und beschreiben, wie die Endbenutzerauthentifizierung durchgeführt wurde. Die Bezeichner liegen außerhalb des Geltungsbereichs der OIDC-Spezifikation. So definiert jedes OP sein eigenes. Dieser Anspruch ist fakultativ.

“Azp” (Authorized Party) Claim: Die Partei, an die der ID-Token ausgestellt wurde. Falls vorhanden, MUSS es die OAuth 2.0-Client-ID dieser Partei enthalten. Dies ist nur erforderlich, wenn das Audience-Array einen einzelnen Wert enthält (die Client-ID des RP) und sich dieser Wert von dem der autorisierten Partei unterscheidet. Dieser Anspruch ist fakultativ.

“At_hash” (Zugriffstoken-Hash-Wert) Claim: Hash-Wert des Zugriffstokens unter Verwendung des im alg-Header-Parameter aufgelisteten Hash-Algorithmus. Dieser Anspruch kann je nach Durchfluss erforderlich sein.

"C_hash" (Berechtigungscode-Hash) Behauptung: Hash-Wert des Code-Parameterwerts unter Verwendung des im Header-Parameter "alg" aufgelisteten Hash-Algorithmus. Grundsätzlich ist dies dasselbe wie der Anspruch "at_hash", jedoch auf dem Autorisierungscode. Dieser Anspruch kann je nach Durchfluss erforderlich sein.

„Sub_jwk“ (selbst herausgegebener öffentlicher OpenID Provider-Signaturschlüssel) Claim: Öffentlicher Schlüssel, mit dem die Signatur eines ID-Tokens überprüft wird, der von einem selbst herausgegebenen (persönlichen, selbst gehosteten OP, der selbst signierte Token ausstellt) -OP ausgegeben wird. Der Schlüssel ist ein leerer Schlüssel im JWK-Format (kein X.509-Format). Wenn das OP nicht selbst ausgestellt ist, sollte diese Behauptung nicht verwendet werden.

Weitere Informationen zu diesen Ansprüchen finden Sie in Abschnitt 2 der OIDC-Spezifikation. Ansprüche, die nicht verstanden werden, müssen ignoriert werden. Das JWT-Token, das als ID-Token fungiert, darf die Felder JWS oder JWE-Header-Parameter nicht enthalten:

  • x5u
  • x5c
  • jku
  • jwk

Stattdessen sollten diese Informationen über das Discovery-Dokument des OP oder auf andere Weise bereitgestellt werden (siehe Abschnitt 10 der OIDC-Spezifikation).

Die OIDC-Spezifikation definiert auch zahlreiche Standardansprüche, die (auf Anfrage) in das ID-Token oder die UserInfo-Antwort aufgenommen werden können. Ob zusätzliche Ansprüche im ID-Token enthalten sind oder vom UserInfo-Endpunkt abgerufen werden, hängt von der vom OP-Anbieter unterstützten Funktionalität ab.

Das als ID-Token fungierende JWT muss signiert (JWS) und optional verschlüsselt (JWE) sein. Wenn Verschlüsselung verwendet wird, muss das JWT signiert und anschließend verschlüsselt werden. Diese Schritte bieten "Authentifizierung, Integrität, Nicht-Zurückweisung und optional Vertraulichkeit".

Wie unterscheidet sich OIDC von OAuth 2.0?

Direkt aus der Spezifikation haben wir „die primäre Erweiterung, die OIDC für OAuth 2.0 vornimmt, um die Authentifizierung von Endbenutzern zu ermöglichen, ist die ID-Token-Datenstruktur.“ OIDC bringt also JWT ins Bild - und macht es durch Erweiterung zu etwas das wird sehr vergleichbar mit dem, was in den SAML2-Anwendungsfällen im Spiel ist.

Die OAuth2- und OIDC-Spezifikationen behandeln viele der gleichen Anwendungsfälle, aber die OAuth2-Spezifikation bezieht sich auf die delegierte Autorisierung (einer Clientanwendung, die auf dem Zugriff basiert, den der Endbenutzer auf seine auf einem Drittanbieter gehosteten Ressourcen gewährt) Server). Die OAuth2-Spezifikation befasst sich mit einer Vielzahl von Anwendungsfällen, die über die dreibeinige OAuth hinausgehen. Hier begann jedoch die ursprüngliche OAuth-Spezifikation und welche OIDC-Erweiterung. In jedem Fall liegt der Schwerpunkt auf der delegierten Autorisierung. Die Details zur Funktionsweise der Authentifizierung und zu erweiterten authentifizierungsbezogenen Funktionen werden in OAuth2 nicht definiert. Hier beginnt OIDC. OIDC ist ein Authentifizierungsprotokoll. Es basiert auf dem OAuth2 Authorization Code Grant. Anders ausgedrückt ist OIDC ein OAuth2-Profil.

OIDC fügt OAuth2 die folgenden Authentifizierungsfunktionen hinzu:

  • Standardisierung von Ansprüchen (die Standardmenge von Ansprüchen, die im ID-Token enthalten ist).
  • Erzwingt die Verwendung eines digital signierten (und optional verschlüsselten) Tokens (JWT) als ID-Token-Datenstruktur, die Benutzerinformationen enthält (Claims). Interessanterweise kann dies auch dadurch erreicht werden, dass das Zugriffstoken selbst ein JWT sein muss. Dies hat jedoch Auswirkungen auf die Sicherheit, die wir später untersuchen werden. Die Einführung des ID-Tokens bedeutet, dass der Authentifizierungsschritt auf dem RP jetzt auf dem ID-Token und nicht auf dem Zugriffstoken beruht (im Gegensatz zu OAuth2).
  • Bietet einen SAML2-SAML-Artefakt-ähnlichen Mechanismus über den UserInfo-Endpunkt. Auf diese Weise kann festgelegt werden, welche Behauptungen von verschiedenen Akteuren gesehen werden.
  • Ermöglicht das Erzwingen der Authentifizierung eines Endbenutzers (auch wenn dieser bereits am OP angemeldet ist)
  • Möglichkeit für Kunden, zusätzliche Ansprüche anzufordern (ID-Token oder Benutzerinfo-Endpunkt, wie zuvor erläutert)
  • Identifizieren Sie, wie der Endbenutzer authentifiziert wurde (dh den Authentifizierungskontext (acr claim) im ID-Token).
  • Schutzstufe für Zugriffstoken. Dies bezieht sich auf die Verwendung von Verschlüsselung (JWE) und Signaturen (JWS) auf dem ID-Token. Diese Details würden während des Client-Registrierungsprozesses konfiguriert. Bei der Recherche in diesem Artikel habe ich nach einem Laufzeitmechanismus (Parameter, der an eine Authentifizierungsanforderung angehängt ist) gesucht, mit dem der Client angeben kann, welche Schutzstufe im ID-Token enthalten sein soll. Es scheint jedoch keinen zu geben .
  • Unterstützung für verteilte und aggregierte Schadensfälle. In dieser Reihe von Beiträgen werden diese Funktionen nicht näher erläutert. Siehe Abschnitt 5.6.2 der OIDC-Spezifikation.
  • Dynamische Einführungen (Kundeneinführungen und Onboarding). Ebenso wird auf dieses Thema nicht näher eingegangen.

OIDC-Endpunkte

Ein OP kündigt die folgenden Endpunkte an.

Berechtigungsendpunkt

Der Autorisierungsendpunkt wird durch die OAuth2-Spezifikation definiert. Dieser Endpunkt ist für die Authentifizierung und das Einholen der Zustimmung des Endbenutzers verantwortlich. Weitere Details finden Sie hier. OIDC-Anforderungen an diesen Endpunkt bestehen aus Parametern, die in den OAuth2- und OIDC-Spezifikationen definiert sind. Siehe die Diskussion der Authentifizierungsabläufe weiter unten.

Token-Endpunkt

Der Token-Endpunkt wird auch durch die OAuth2-Spezifikation definiert. Dieser Endpunkt ist dafür verantwortlich, dass ein Client einen Autorisierungscode oder eine Clientkennung und ein Clientgeheimnis gegen ein Zugriffstoken austauschen kann. Weitere Details finden Sie hier. OIDC-Anforderungen an diesen Endpunkt bestehen aus Parametern, die in den OIDC-Spezifikationen definiert sind. Siehe die Diskussion der Authentifizierungsabläufe weiter unten.

UserInfo-Endpunkt

Der UserInfo-Endpunkt wird durch die OIDC-Spezifikation definiert. Es ermöglicht einem Akteur (Client oder Resource Server), zusätzliche Ansprüche anzufordern.

Um den Standardsatz von Ansprüchen vom UserInfo-Endpunkt des OpenID-Providers abzurufen, muss eine Anforderung gesendet werden, die der folgenden ähnelt (wobei das Token im Authorization-Header das Zugriffstoken ist, das dem Client präsentiert wurde).

GET / oidc / userinfo HTTP / 1.1
Host: server.example.com
Genehmigung: Inhaber PHNhbWxwOl… [der Kürze halber weggelassen]… ZT4

Die Antwort würde ungefähr so ​​aussehen.

HTTP / 1.1 200 OK
  Inhaltstyp: Anwendung / json

  {
   "sub": "john.smith@levvel.io",
   "name": "John Smith",
   "Vorname": "John",
   "family_name": "Smith",
   "preferred_username": "john.smith@levvel.io",
   "email": "john.smith@levvel.io"
  }

Wenn der Akteur eine Signatur und / oder Verschlüsselung anfordert, wird eine JWT mit der entsprechenden Anwendung der JWS- und JWE-Spezifikationen zurückgesandt.

Zusammenfassung

Dieser Beitrag enthält eine Einführung in die OIDC-Konzepte. Im nächsten Beitrag werden wir uns mit den Authentifizierungsabläufen befassen, die in der OIDC-Spezifikation definiert sind.

Fragen? Bemerkungen? Poste sie unten.