Erteilungstypen

Online bearbeiten

Ein Erteilungstyp gibt den Berechtigungsmechanismus an, den der Client verwendet, um das ID-Token und das Zugriffstoken aus Verifyabzurufen. Sie können zwischen Berechtigungscode, implizit, Berechtigungscode und implizit, Geräteablauf, Ressourceneignerberechtigungsnachweise, JWT, kontextbasierte Berechtigung, Aktualisierungstokenund Tokenaustauschwä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örderungsarten
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.

Sie dient zur Authentifizierung des Benutzers und des Clients.

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 kann der Benutzername als Zeichenfolge sein, z. B. john@ibm.com, oder ein JSON-Wert. Beispiel:
{"realm":"securityVerifyRealm",
"username":"john@ibm.com"}
. Wenn ein JSON-Wert verwendet wird, stellt das Realm das Identitätsquellenrealm dar.
 Ja
Dieser Wert kann der Benutzername als Zeichenfolge sein, z. B. john@ibm.com, oder ein JSON-Wert. Beispiel:
{"realm":"securityVerifyRealm",
"username":"john@ibm.com"}
. Wenn ein JSON-Wert verwendet wird, stellt das Realm das Identitätsquellenrealm dar.
 Ja
Dieser Wert kann der Benutzername als Zeichenfolge sein, z. B. john@ibm.com, oder ein JSON-Wert. Beispiel:
{"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 Anforderung an den Verify Authorization Server.
  3. Der Verify Authorization Server authentifiziert den Benutzer.
  4. Der Verify Authorization Server ruft die Zustimmung oder Berechtigung des Benutzers ab.
  5. Der Verify Authorization Server sendet den Benutzer mit einem Berechtigungscode zurück an den Client.
  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 Anforderung an den Verify Authorization Server.
  3. Der Verify Authorization Server authentifiziert den Benutzer.
  4. Der Verify Authorization Server ruft die Zustimmung oder Berechtigung des Benutzers ab.
  5. Der Verify Authorization Server sendet den Benutzer mit einem ID-Token und, falls angefordert, einem Zugriffstoken zurück an den Client.
  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 Anforderung an den Verify Authorization Server.
  3. Der Verify Authorization Server authentifiziert den Benutzer.
  4. Der Verify Authorization Server ruft die Zustimmung oder Berechtigung des Benutzers ab.
  5. Der Verify Authorization Server sendet den Benutzer mit einem Berechtigungscode und je nach Antworttyp mindestens einem Parameter zurück an den Client.
  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örderungsarten fortgesetzt
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örderungsarten fortgesetzt
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. Die Client-und Benutzerauthentifizierung ist erforderlich, indem eine Client-ID, ein geheimer Clientschlüssel und ein Aktualisierungstoken verwendet werden, um eine neue Gruppe von Zugriffstoken, ID-Token und Aktualisierungstoken vom Tokenendpunkt/Token abzurufen. Das Aktualisierungstoken muss derselben Client-ID angehören. Dem Token zugeordnete Attributwerte werden während dieses Ablaufs nicht aktualisiert. Definiert in RFC8693. Ermöglicht einem Client die Präsentation eines Tokens, das gegen ein anderes Token ausgetauscht 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 diesen Erteilungstyp, um eine neue Gruppe von Zugriffstoken mit verlängerter Tokenlebensdauer abzurufen. Auf diese Weise kann die Lebensdauer des Zugriffstokens kurz gehalten werden, der Benutzer muss sich jedoch nicht erneut anmelden, um ein neues Zugriffstoken zu erhalten.

  • Identitätswechsel: Damit ein Client als andere Entität auf eine Ressource zugreifen kann.

  • Delegierung: Für einen Kunden, der im Namen einer berechtigten Entität 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 Anforderung unter Verwendung von grant_type=Context-based authorization vorlegt.
  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, ob das Zugriffstoken abläuft oder abgelaufen ist, und möchte Zugriffstoken abrufen.
  2. Der Client sendet die Clientberechtigungsnachweise und das Aktualisierungstoken an den Tokenendpunkt.
  3. Das Aktualisierungstoken und die Clientberechtigungsnachweise werden validiert.
  4. Der Client empfängt eine Antwort, die ein ID-Token, ein Aktualisierungstoken und ein Zugriffstoken im Antworthauptteil enthält.

  1. Der Client generiert oder ruft ein Token ab, das als Subjekttoken verwendet werden soll. Optional verfügt er auch über ein Akteurtoken.

  2. Senden Sie eine Anforderung mit dem Subjekttoken und optional mit dem Akteurtoken an den Tokenendpunkt des Berechtigungsservers.

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