Berechtigungstyp "Implizit"

Verwenden Sie diesen Berechtigungstyp, wenn die benutzerdefinierte Anwendung 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-Ablauf:

  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 die 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 z.B. eine Benutzerliste.

Funktion Verfügbar
Erfordert Clientauthentifizierung Nein
Erfordert, dass der Client Benutzerzugangsdaten kennt Nein
Browserbasierte Endbenutzerinteraktion Ja
Kann einen externen Identitätsprovider für die Authentifizierung verwenden Ja
Aktualisierungstoken ist zulässig Nein
Zugriffstoken befindet sich im Kontext des Endbenutzers Ja

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

Beispiel für einen Autorisierungsablauf im impliziten Berechtigungstyp

Dieses Beispiel für eine implizite Berechtigungstypautorisierung beschreibt den Autorisierungsablauf für Anwendungen, die in einem Webbrowser mit einer Skriptsprache wie JavaScript implementiert oder auf einem Mobilgerä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 dies ein Mobile Application-Typ ist.

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

Weitere Informationen zum impliziten Berechtigungstyp und einem Autorisierungsflussdiagramm finden Sie unter Impliziter Berechtigungstyp.

Verarbeitungsschritte

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

  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 zufällige Zeichenfolge, die Sie verwenden, um zu verhindern, dass abgefangene Antworten wiederverwendet werden.

    Beispielanforderung mit mTLS

    Informationen zum Abrufen der secureDomainURL finden Sie unter Zugriffsberechtigungstypen.

    curl -v \
    --cert cert.crt \
    --key key.key \
    --cacert ca.crt \
    --location '<secureDomainURL>/oauth2/v1/token' \
    --header 'Authorization: Basic <base64Encoded clientid:secret>'
    --header 'Content-Type: application/x-www-form-urlencoded' \
    --data-urlencode 'grant_type=client_credentials' \
    --data-urlencode 'client_id=<client-id>' \
    --data-urlencode 'scope=urn:opc:idm:_myscopes_'
  3. Wenn der Benutzer noch nicht angemeldet ist, fordert der Autorisierungsserver OAuth den Benutzer zur Authentifizierung auf. Der OAuth-Autorisierungsserver authentifiziert den Benutzer und stellt eine Einwilligungsseite bereit, auf der der der Benutzer die gemeinsame Nutzung von Informationen autorisieren kann.

  4. Nachdem der Benutzer autorisiert hat, leitet der Autorisierungsserver OAuth den Browser mit einem Zugriffstoken zur anfordernden Site um.
    Hinweis

    Wenn sich der Benutzer nicht authentifiziert, wird anstelle des Zugriffstokens ein Fehler zurückgegeben.
  5. Das Zugriffstoken wird mit allen anwendbaren Geltungsbereichen basierend auf den Berechtigungen zurückgegeben, die durch die Anwendungsrollen repräsentiert werden, die der anfordernden Clientanwendung erteilt wurden, und dem Benutzer, der durch die Anforderung des Clients (falls vorhanden) angegeben wird.

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