Erteilungstypen

Online bearbeiten

VerifyEin Grant-Typ gibt den Autorisierungsmechanismus an, den der Client verwendet, um das ID-Token und das Zugriffstoken abzurufen. Sie können zwischen Autorisierungscode, impliziter Autorisierung, Autorisierungscode und impliziter Autorisierung, Geräteablauf, Anmeldedaten des Ressourcenbesitzers, JWT, kontextbasierter Autorisierung, Aktualisierungstoken und Tokenaustausch wählen.

Die folgenden Tabellen, die einen Vergleich der unterstützten Erteilungstypen zeigen, unterstützen Sie bei der Bestimmung des für die Anwendung festzulegenden Erteilungstyps.
Tabelle 1. Förderarten
Merkmale Berechtigungscode Implizit Berechtigungscode und Implizit
Beschreibung

Der Berechtigungsendpunkt /authorize gibt einen Berechtigungscode zurück. Der Berechtigungscode kann dann gegen ein ID-Token, ein Zugriffstoken oder ein Aktualisierungstoken ausgetauscht werden.

Clientauthentifizierung unter Verwendung einer Client-ID und eines geheimen Schlüssels ist erforderlich, um das ID-Token oder das Zugriffstoken vom Tokenendpunkt /token abzurufen.

Dies ist der am häufigsten verwendete Ablauf.

Der Berechtigungsendpunkt /authorize gibt ein ID-Token oder ein Zugriffstoken direkt zurück.

Er verwendet keinen Berechtigungscode und keinen Tokenendpunkt /token.

Er ermöglicht dem Client-Front-End und -Back-End, Tokens jeweils unabhängig voneinander zu empfangen.

Der Client ruft einen Berechtigungscode und Tokens vom Berechtigungsendpunkt /authorize ab. Einige Tokens werden vom Tokenendpunkt /token angefordert.
Anwendungsfall

Verwendung für Clients, die einen geheimen Clientschlüssel sicher verwalten können, wie beispielsweise Webanwendungen und native mobile Anwendungen.

Damit sollen der Benutzer und der Client authentifiziert werden.

Verwendung für Clients, die einen geheimen Clientschlüssel nicht sicher verwalten können, wie beispielsweise der Browser oder JavaScript-basierte Anwendungen.

Dient zur Authentifizierung des Benutzers.
Verwendung für Clients, die:
  • einen geheimen Clientschlüssel sicher verwalten können, wie beispielsweise Webanwendungen und native mobile Anwendungen,
  • für Identitätsinformationen unmittelbaren Zugriff auf das ID-Token erfordern,
  • langlebige Tokens durch die Verwendung von Aktualisierungstokens erfordern.
Antworttypwert 
code
 
id_token
token
id_token token
 
code id_token
code token
code id_token token
Alle Tokens werden vom Berechtigungsendpunkt zurückgegeben. Nein Ja Nein
Alle Tokens werden vom Tokenendpunkt zurückgegeben. Ja Nein Nein
Tokens werden dem Benutzeragenten gegenüber nicht offengelegt. Ja Nein Nein
Clientanwendung kann authentifiziert werden. Ja Nein Ja
Aktualisierungstokens generieren Ja Nein Ja
Kommunikation in einem einzigen Umlauf Nein Ja Nein
Der größte Teil der Kommunikation erfolgt als Kommunikation zwischen Servern. Ja Nein Unterschiedlich
Hinweis zur Anmeldung (login_hint) Ja
Dieser Wert könnte beispielsweise der Benutzername als Zeichenfolge sein, z. B. john@ibm.com, oder ein JSON-Objekt, z. B
{"realm":"securityVerifyRealm",
"username":"john@ibm.com"}
. Wenn ein JSON-Wert verwendet wird, stellt das Realm das Identitätsquellenrealm dar.
 Ja
Dieser Wert könnte beispielsweise der Benutzername als Zeichenfolge sein, z. B. john@ibm.com, oder ein JSON-Objekt, z. B
{"realm":"securityVerifyRealm",
"username":"john@ibm.com"}
. Wenn ein JSON-Wert verwendet wird, stellt das Realm das Identitätsquellenrealm dar.
 Ja
Dieser Wert könnte beispielsweise der Benutzername als Zeichenfolge sein, z. B. john@ibm.com, oder ein JSON-Objekt, z. B
{"realm":"securityVerifyRealm",
"username":"john@ibm.com"}
. Wenn ein JSON-Wert verwendet wird, stellt das Realm das Identitätsquellenrealm dar.
Maximale Gültigkeitsdauer der Authentifizierung (max_age) Dieser Wert gibt die seit der letzten aktiven Authentifizierung des Benutzers zulässige abgelaufene Zeit in Sekunden an. Dieses Attribut gilt nur für Cloud Directory-Anmeldesitzungen. Dieser Wert gibt die seit der letzten aktiven Authentifizierung des Benutzers zulässige abgelaufene Zeit in Sekunden an. Dieses Attribut gilt nur für Cloud Directory-Anmeldesitzungen. Dieser Wert gibt die seit der letzten aktiven Authentifizierung des Benutzers zulässige abgelaufene Zeit in Sekunden an. Dieses Attribut gilt nur für Cloud Directory-Anmeldesitzungen.
Workflow
  1. Der Client bereitet eine Authentifizierungsanforderung vor, die die erforderlichen Anforderungsparameter enthält.
  2. Der Client sendet die Anfrage an den Verify Autorisierungsserver.
  3. Der Verify Autorisierungsserver authentifiziert den Benutzer.
  4. Der Verify Autorisierungsserver holt die Zustimmung oder Autorisierung des Benutzers ein.
  5. Der Verify Autorisierungsserver leitet den Benutzer mit einem Autorisierungscode an den Client zurück.
  6. Der Client fordert unter Verwendung des Berechtigungscodes am Tokenendpunkt eine Authentifizierungsantwort an.
  7. Der Client empfängt eine Antwort, die ein ID-Token und ein Zugriffstoken im Antworthauptteil enthält.
  8. Der Client validiert das ID-Token und ruft die Subjekt-ID des Benutzers ab.
  1. Der Client bereitet eine Authentifizierungsanforderung vor, die die erforderlichen Anforderungsparameter enthält.
  2. Der Client sendet die Anfrage an den Verify Autorisierungsserver.
  3. Der Verify Autorisierungsserver authentifiziert den Benutzer.
  4. Der Verify Autorisierungsserver holt die Zustimmung oder Autorisierung des Benutzers ein.
  5. Der Verify Autorisierungsserver leitet den Benutzer mit einem ID-Token und, falls angefordert, einem Zugriffstoken an den Client zurück.
  6. Der Client validiert das ID-Token und ruft die Subjekt-ID des Benutzers ab.
  1. Der Client bereitet eine Authentifizierungsanforderung vor, die die erforderlichen Anforderungsparameter enthält.
  2. Der Client sendet die Anfrage an den Verify Autorisierungsserver.
  3. Der Verify Autorisierungsserver authentifiziert den Benutzer.
  4. Der Verify Autorisierungsserver holt die Zustimmung oder Autorisierung des Benutzers ein.
  5. Der Verify Autorisierungsserver leitet den Benutzer mit einem Autorisierungscode und – je nach Antworttyp – einem oder mehreren Parametern an den Client zurück.
  6. Der Client fordert unter Verwendung des Berechtigungscodes am Tokenendpunkt eine Antwort an.
  7. Der Client empfängt eine Antwort, die ein ID-Token und ein Zugriffstoken im Antworthauptteil enthält.
  8. Der Client validiert das ID-Token und ruft die Subjekt-ID des Benutzers ab.
Tabelle 2. Förderarten (Fortsetzung)
Merkmale Geräteablauf Kennwortberechtigungsnachweise für Ressourceneigner JWT
Beschreibung Ermöglicht dem Client die Berechtigung mithilfe eines QR-Codes oder eines Benutzercodes, der an eine URL gesendet wird. Client- und Benutzerauthentifizierung unter Verwendung einer Client-ID, eines geheimen Clientschlüssels, eines Benutzernamens und eines Kennworts ist erforderlich, um das Zugriffstoken und das ID-Token vom Tokenendpunkt /token abzurufen. Der Benutzername und das Kennwort werden mithilfe von Cloud Directory validiert. In RFC7523 definiert. Ermöglicht es einem Client, ein signiertes oder verschlüsseltes JWT oder ein signiertes und verschlüsseltes JWT im Austausch für eine Erteilung bereitzustellen. Das JWT wird vom Berechtigungsserver validiert und die Identität in dem JWT wird als das Subjekt der Erteilung verwendet.
Anwendungsfall
Verwendung für Clients, die:
  • über keinen Browser zur Ausführung eines benutzeragentenbasierten OAuth-Ablaufs verfügen,
  • in Bezug auf die Eingabe soweit eingeschränkt sind, dass eine erforderliche umfangreiche Texteingabe des Benutzers nicht praktikabel ist.
Einige Beispiele sind Smart-TVs, Medienkonsolen, digitale Bilderrahmen und Drucker.
 Dieser Erteilungstyp kann zwar aktiviert werden, er sollte jedoch nur verwendet werden, wenn keine anderen Abläufe verfügbar sind. Er kann für Folgendes verwendet werden:
  • Ressourceneigner, die über eine Vertrauensbeziehung mit dem Client verfügen, beispielsweise das Betriebssystem des Geräts oder eine Anwendung mit umfassenden Berechtigungen
  • Clients, die die Berechtigungsnachweise des Ressourceneigners (Benutzername und Kennwort) unter Verwendung eines interaktiven Formulars abrufen können
  • Migration vorhandener Clients, die Schemas für die direkte Authentifizierung, wie beispielsweise die HTTP-Basisauthentifizierung oder Digest-Authentifizierung, bei OAuth verwenden, indem die gespeicherten Berechtigungsnachweise in ein Zugriffstoken konvertiert werden.
 Zwischen dem Berechtigungsserver (Verify) und einer Entität, die JWTs ausstellt, besteht eine Vertrauensbeziehung. Der Client ruft von der Entität, die JWTs ausstellt, ein JWT ab und stellt es dem Berechtigungsserver im Austausch für eine Erteilung zur Verfügung. Für die Entität, die JWTs ausstellt, sind möglicherweise eigene Anforderungen vorhanden, die erfüllt sein müssen, bevor ein JWT ausgestellt wird (wie beispielsweise alternative Authentifizierungs- und Berechtigungsprüfungen).
Antworttypwert Nicht zutreffend Nicht zutreffend Nicht zutreffend
Alle Tokens werden vom Berechtigungsendpunkt zurückgegeben. Nein Nein Nein
Alle Tokens werden vom Tokenendpunkt zurückgegeben. Ja Ja Ja
Tokens werden dem Benutzeragenten gegenüber nicht offengelegt. Ja Ja Ja
Clientanwendung kann authentifiziert werden. Ja Ja Ja
Aktualisierungstokens generieren Ja Ja Ja
Kommunikation in einem einzigen Umlauf
Der größte Teil der Kommunikation erfolgt als Kommunikation zwischen Servern.
Hinweis zur Anmeldung (login_hint) Nein Nein Nein
Maximale Gültigkeitsdauer der Authentifizierung (max_age) Nicht zutreffend
Workflow
  1. Der Benutzer startet den Ablauf, indem er die Client-ID von dem Gerät zum Anfordern eines Benutzercodes und Gerätecodes sendet.
  2. Wenn die Client-ID gültig ist, werden der Verifizierung-URI, der Benutzercode und der Gerätecode zurückgegeben.
  3. Das Gerät zeigt entweder den Verifizierung-URI und den Benutzercode an, den der Benutzer in einen Browser eingeben kann, oder es zeigt einen QR-Code an, den der Benutzer scannen kann.
  4. Das Gerät versucht kontinuierlich, den Gerätecode gegen ein Token auszutauschen.
  5. Der Benutzer scannt den Verifizierung-URI und den Benutzercode oder er gibt diese manuell ein, um den Benutzercode an den OIDC-Service zu senden.
  6. Wenn der Benutzercode gültig ist, wird eine Nachricht über die erfolgreiche Ausführung gesendet und der Gerätecode wird gegen ein Zugriffstoken ausgetauscht.
  1. Der Benutzer gibt den Benutzernamen und das Kennwort in ein Formular der Relying Party ein.
  2. Der Client sendet den Benutzernamen, das Kennwort, die Client-ID und den geheimen Clientschlüssel an den Tokenendpunkt.
  3. Der Benutzername und das Kennwort werden mithilfe von Cloud Directory validiert.
  4. Der Client empfängt eine Antwort, die ein ID-Token und ein Zugriffstoken im Antworthauptteil enthält.
  1. Der Client ruft ein JWT (mithilfe externer Mittel) ab und stellt es dem Endpunkt zur Verfügung.
  2. Das JWT wird validiert und das Subjekt und weitere Attribute werden extrahiert.
  3. Der Client empfängt eine Antwort, die ein ID-Token und ein Zugriffstoken im Antworthauptteil enthält.
Tabelle 3. Förderarten (Fortsetzung)
Merkmale Kontextbasierte Berechtigung Aktualisierungstoken Tokenaustausch
Beschreibung Ein API-gesteuerter Ablauf, bei dem zusätzliche Authentifizierungs- und Berechtigungsprüfungen ausgeführt werden. Bevor eine Erteilung an den Client ausgegeben wird, ist unter Umständen eine Mehrfaktorauthentifizierung erforderlich. Zur Client- und Benutzerauthentifizierung sind eine Client-ID, ein Client-Secret und ein Refresh-Token erforderlich, um über den Token-Endpunkt /token einen neuen Satz aus Zugriffstoken, ID-Token und Refresh-Token abzurufen. Das Aktualisierungstoken muss zur gleichen Client-ID gehören. Die mit dem Token verknüpften Attributwerte werden während dieses Ablaufs nicht aktualisiert. Definiert unter RFC8693. Ermöglicht es einem Kunden, ein Token vorzulegen, das gegen ein anderes Token eingetauscht werden soll.
Anwendungsfall

  • Der Client muss für die Handhabung einer Antwort des Typs Prüffrage vom Berechtigungsserver instrumentiert sein.

  • Der Client verwendet die Authentifizierungsfaktor-APIs, die in Verify verfügbar sind, um ein JWT zu empfangen, das dann zur Verfügung gestellt wird, um den Ablauf fortzusetzen.
  • Der Client muss zusätzliche Kontextinformationen in der Anforderung über den Parameter 'context' einschließen.
 Verwenden Sie diese Berechtigungsart, um einen neuen Satz von Zugriffstoken mit verlängerter Gültigkeitsdauer zu erhalten. Dadurch kann die Gültigkeitsdauer des Zugriffstokens kurz gehalten werden, ohne dass sich der Benutzer erneut anmelden muss, um ein neues Zugriffstoken zu erhalten.

  • Identitätsdiebstahl: Wenn ein Client als eine andere Entität Zugriff auf eine Ressource erhält.

  • Beauftragung: Wenn ein Auftraggeber im Namen einer bevollmächtigten Stelle handelt.
Antworttypwert Nicht zutreffend Nicht zutreffend Nicht zutreffend
Alle Tokens werden vom Berechtigungsendpunkt zurückgegeben. Nein Nein Nein
Alle Tokens werden vom Tokenendpunkt zurückgegeben. Ja Ja Ja
Tokens werden dem Benutzeragenten gegenüber nicht offengelegt. Ja Ja Ja
Clientanwendung kann authentifiziert werden. Ja Ja Ja
Aktualisierungstokens generieren Ja Ja Ja
Kommunikation in einem einzigen Umlauf Ja
Der größte Teil der Kommunikation erfolgt als Kommunikation zwischen Servern. Ja
Hinweis zur Anmeldung (login_hint) Nein Nein Nein
Maximale Gültigkeitsdauer der Authentifizierung (max_age) Nicht zutreffend Nein
Workflow
  1. Der Client leitet den Ablauf ein, indem er einen `Kontext` mit einer Anfrage über grant_type=Context-based authorization
  2. Der Client empfängt entweder DENY (wenn der Zugriff in diesem Kontext nicht zulässig sein soll) oder CHALLENGE (angegeben über den zurückgegebenen Geltungsbereich).
  3. Mithilfe des Zugriffstokens, das mit der Antwort auf Prüffrage zurückgegeben wird, greift der Client auf die verfügbaren Authentifizierungsfaktor-APIs, einschließlich des Flags zum Anfordern eines JWT infolge der Ausführung einer Authentifizierung mit Faktor, zu.
  4. Das JWT, das von der abgeschlossenen Authentifizierung mit Faktor zurückgegeben wird, wird wieder dem /token als JWT-Träger-Erteilungsanforderung (auch der Kontext muss eingeschlossen sein) zur Verfügung gestellt und Tokens werden ausgestellt.
Hinweis:
  • Abhängig von der konfigurierten Richtlinie sind nach der Ausführung der Authentifizierung mit dem ersten Faktor gegebenenfalls weitere Faktoren erforderlich. Diese Faktoren erfordern unter Umständen die Ausführung einer zweiten Abfrage (CHALLENGE) und einer Authentifizierung mit einem zweiten Authentifizierungsfaktor.
  • Dieser Erteilungstyp erfordert die Erstellung einer angepassten Zugriffsrichtlinie, die der Anwendung zugeordnet werden muss. Diese Zugriffsrichtlinie muss Regeln für die Authentifizierung mit dem ersten Faktor und wahlweise alle 2FA-Anforderungen enthalten.
  1. Der Client stellt fest, dass das Zugriffstoken bald abläuft oder bereits abgelaufen ist, und möchte neue Zugriffstoken abrufen.
  2. Der Client sendet die Client-Anmeldedaten und das Aktualisierungstoken an den Token-Endpunkt.
  3. Das Aktualisierungstoken und die Client-Anmeldedaten werden überprüft.
  4. Der Client erhält eine Antwort, deren Antworttext ein ID-Token, ein Aktualisierungstoken und ein Zugriffstoken enthält.

  1. Der Client generiert oder ruft ein Token ab, das als Subjekt-Token verwendet werden soll. Optional wird es auch ein Akteur-Token enthalten.

  2. Sende eine Anfrage an den Token-Endpunkt des Autorisierungsservers mit dem Betreff-Token und optional dem Akteur-Token.

  3. Der Autorisierungsserver gibt das angeforderte Token zurück.