Impliziter Berechtigungstyp

Verwenden Sie diesen Berechtigungstyp, wenn die benutzerdefinierte Anwendung die Clientzugangsdaten nicht vertraulich behandeln kann und ein Zugriffstoken direkt von einer Autorisierungsanforderung und nicht über einen Zwischenautorisierungscode empfängt.

Das folgende Diagramm zeigt den Ablauf "Impliziter Berechtigungstyp".

Ein Diagramm, das den Ablauf "Impliziter Berechtigungstyp" veranschaulicht.

In diesem OAuth-Fluss:

  1. Beispiel: Eine benutzerdefinierte Anwendung wird in einer clientseitigen Anwendung mit einer Skriptsprache wie JavaScript implementiert oder für ein mobiles Gerät implementiert. Der Benutzer fordert Authentifizierung und Autorisierung über die Anwendung an.

  2. Die Clientanwendung fordert den Benutzer auf, seine Zugangsdaten anzugeben.

  3. Der Benutzer gibt seine Zugangsdaten ein.

  4. Wenn der Benutzer autorisiert ist, wird er zu einer URL umgeleitet, die das Zugriffstoken in einem URL-Fragment enthält.

  5. Die Anwendung extrahiert das Zugriffstoken aus der URL.

  6. Die Anwendung verwendet das Zugriffstoken in einer Anforderung für geschützte Ressourcen, wie einer Benutzerliste.

Funktion Verfügbare
Clientauthentifizierung erforderlich Nein
Client muss Benutzerzugangsdaten kennen Nein
Browserbasierte Endbenutzerinteraktion Ja
Kann externen Identitätsprovider zur Authentifizierung verwenden Ja
Tokenaktualisierung ist zulässig Nein
Zugriffstoken befindet sich im Kontext des Endbenutzers Ja

Siehe ein Beispiel für den Autorisierungsablauf "Impliziter Berechtigungstyp".

Impliziter Berechtigungsart-Autorisierungsablauf - Beispiel

Dieses Autorisierungsbeispiel für den Berechtigungstyp "Implizit" beschreibt den Autorisierungsablauf für Anwendungen, die in einem Webbrowser mit einer Skriptsprache wie JavaScript implementiert oder auf einem mobilen Gerät implementiert sind. Ein Zugriffstoken wird (anstelle eines Zwischenautorisierungscodes) über eine Browserumleitung als Antwort auf die Autorisierungsanforderung des Ressourceneigentümers an den Client zurückgegeben.

Wenn Sie eine Anwendung für die clientseitige Anwendungsautorisierung in der Identitätsdomainkonsole erstellen:

  • Geben Sie an, dass es sich um einen Mobile Application-Typ handelt.

  • Wählen Sie als Berechtigungstyp Implizit aus. Dieser Anwendungstyp kann kein Secret speichern und wird auf einem nicht authentifizierten Webbrowser oder einem mobilen Gerät ausgeführt.

Weitere Informationen zum Berechtigungstyp "Implizit" und einem Autorisierungsablaufdiagramm finden Sie unter Zugriffsberechtigungstyp "Implizit".

Verarbeitungsschritte

  1. Ein Benutzer klickt auf einen Anmeldelink in seiner Browseranwendung oder tippt auf eine Anmeldeschaltfläche auf seinem Gerät, um Zugriff auf geschützte Ressourcen von einer Clientanwendung anzufordern.

  2. Der Client leitet den Browser mit einer Autorisierungsanforderung an den Autorisierungsserver OAuth um.

    Die Anmelde-URL enthält Abfrageparameter, die den angeforderten Zugriffstyp angeben:

    Beispielanforderung https://acme.identity.us.oraclecloud.com/oauth2/v1/authorize?client_id=<client-id>&response_type=token&redirect_uri=<client-redirect-uri>&scope=<scope>&nonce=<nonce-value>
    Hinweis

    Ein Nonce-Wert ist eine kryptografisch starke Zufallszeichenfolge, mit der Sie verhindern können, dass abgefangene Antworten wiederverwendet werden.
  3. Wenn der Benutzer noch nicht angemeldet ist, fordert der Autorisierungsserver OAuth die Authentifizierung des Benutzers auf. Der Autorisierungsserver OAuth authentifiziert den Benutzer und stellt eine Einwilligungsseite bereit, auf der der Benutzer die Freigabe von Informationen autorisieren kann.

  4. Nachdem der Benutzer autorisiert hat, leitet der Autorisierungsserver OAuth den Browser mit einem Zugriffstoken an die anfordernde Site um.
    Hinweis

    Wenn sich der Benutzer nicht authentifiziert, wird anstelle des Zugriffstokens ein Fehler zurückgegeben.
  5. Das Zugriffstoken wird zurückgegeben, das alle anwendbaren Geltungsbereiche enthält, basierend auf den Berechtigungen, die durch die Anwendungsrollen dargestellt werden, die der anfordernden Clientanwendung erteilt wurden, und dem Benutzer, der durch die Clientanforderung angegeben wird (sofern vorhanden).

  6. Die anfordernde Site verwendet das Zugriffstoken in einem API-Aufruf, um geschützte Daten abzurufen.