Oracle Cloud Infrastructure - Dokumentation

Berechtigungstyp "TLS-Clientauthentifizierung"

Verwenden Sie den Berechtigungstyp Transport Layer Security (TLS), wenn der Autorisierungsgeltungsbereich auf die geschützten Ressourcen unter der Kontrolle des Clients oder zum Schutz von Ressourcen beschränkt ist, die beim OAuth-Autorisierungsserver registriert sind.

Das folgende Diagramm zeigt den Ablauf "Berechtigungstyp für TLS-Clientauthentifizierung".

Ein Diagramm, das den Erteilungstyp für die TLS-Clientauthentifizierung veranschaulicht.
In diesem OAuth-Fluss:
Hinweis

Voraussetzung: Laden Sie das Clientzertifikat in den Clientzertifikatspeicher hoch.
  1. Im Rahmen des TLS-Handshakes stellt die Clientanwendung ein eigenes Zertifikat und eine eigene Client-ID vor, um ein Zugriffstoken abzurufen. Hinweis: Dieses Zertifikat muss mit dem Zertifikat im Clientzertifikatsspeicher übereinstimmen.
  2. Dieses angeforderte Zugriffstoken ist entweder mit den eigenen Ressourcen des Clients, aber nicht mit einem bestimmten Ressourceneigentümer, oder mit einem Ressourceneigentümer verknüpft, für den die Clientanwendung anderweitig berechtigt ist, Aktionen auszuführen.
  3. Der Autorisierungsserver gibt das Zugriffstoken erst nach erfolgreicher Zertifikatsvalidierung an die Clientanwendung zurück.
  4. Die Clientanwendung verwendet das Zugriffstoken in einem API-Aufruf, um die App zu aktualisieren.
Funktion Verfügbare
Clientauthentifizierung erforderlich Ja
Client muss Benutzerzugangsdaten kennen Nein
Browserbasierte Endbenutzerinteraktion Nein
Kann externen Identitätsprovider zur Authentifizierung verwenden Nein
Tokenaktualisierung ist zulässig Nein
Zugriffstoken befindet sich im Kontext der Clientanwendung Ja

Ein Beispielablauf finden Sie unter Beispiel für Autorisierungsablauf beim Typ der TLS-Clientauthentifizierung.

Beispiel für Autorisierungsablauf für Berechtigungserteilung für TLS-Clientauthentifizierung

Der Berechtigungstyp "Transport Layer Security-(TLS-)Clientauthentifizierung" stellt einen bestimmten Berechtigungsfluss bereit, an dem der Ressourceneigentümer nicht beteiligt ist. In diesem Szenario führt die Clientanwendung Prozesse aus, die nicht über die Beteiligung des Ressourceneigentümers verfügen, z.B. einen Batchprozess oder eine Server-zu-Server-Aufgabe.

Wenn Sie diesen Berechtigungstyp verwenden, fordert die Clientanwendung zusammen mit der Client-ID ein Zugriffstoken mit einem eigenen Zertifikat (das im Clientprofil hochgeladene Zertifikat) an und verwendet das Zugriffstoken im Namen der Clientanwendung selbst. Dieser Berechtigungsfluss eignet sich am besten, wenn ein Serviceprovider einige API-Methoden bereitstellen möchte, die von der Clientanwendung im Allgemeinen anstelle von API-Methoden verwendet werden sollen, die für einen bestimmten Ressourceneigentümer gelten. Beispiel: API-Methoden für die Wartung.

Wenn Sie eine Anwendung mit dem Berechtigungstyp "TLS-Clientauthentifizierung" in der Identitätsdomainkonsole erstellen:
  • Geben Sie die vertrauliche Anwendung als Anwendungstyp an. Mobile/Browser-Anwendungen haben kein Clientzertifikat und können den Berechtigungstyp "TLS-Clientauthentifizierung" nicht verwenden.
  • Wählen Sie TLS-Clientauthentifizierung als Berechtigungstyp aus.
  • Wählen Sie unter Clienttyp die Option Vertrauenswürdig oder Vertraulich aus.
  • Importieren Sie das Clientzertifikat. Dieses Zertifikat wird zur Validierung der Tokenanforderung verwendet. Hinweis: Der Client muss dasselbe Zertifikat in der Tokenanforderung verwenden.

Weitere Informationen zum Berechtigungstyp "TLS-Clientauthentifizierung" und zu einem Autorisierungsflussdiagramm finden Sie unter Berechtigungstyp "TLS-Clientauthentifizierung".

  1. Ein vom Client initiiertes Ereignis (z.B. eine geplante Aufgabe) fordert Zugriff auf geschützte Ressourcen von einer OAuth-Clientanwendung an.

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

    Beispielanforderung mit dem Autorisierungsheader
    Hinweis

    cacert.crt ist das CA-Zertifikat, das das Zertifikat des Servers für diese TLS signiert hat.

    client.key ist der Private Key des Clients.

    client.crt ist ein Clientzertifikat.

       curl -i
   --cacert cacert.crt --key client.key --cert client.crt
   -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8'
   --request POST https://<domainURL>/oauth2/v1/token 
   -d 'grant_type=tls_client_auth&client_id=<client ID>&scope=<scope value>'

    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_'
  2. Die Clientanwendung fordert ein Zugriffstoken vom Autorisierungsserver OAuth an.
  3. Der Autorisierungsserver OAuth:
    1. Authentifiziert die Clientanwendung basierend auf dem Zertifikat, das als Teil des TLS-Handshakes gesendet wurde.
    2. Gibt ein Zugriffstoken zurück, das alle anwendbaren Geltungsbereiche enthält, basierend auf den Berechtigungen, die von den Anwendungsrollen angegeben werden, die der anfordernden Clientanwendung erteilt wurden.
  4. Die Clientanwendung verwendet das Zugriffstoken, um eine Anforderung auszuführen.