Oracle Cloud Infrastructure - Dokumentation

Berechtigungstyp "Gerätecode"

Verwenden Sie diesen Berechtigungstyp, wenn ein Client auf Geräten ausgeführt wird, die keine einfache Dateneingabemethode haben (z. B. Spielkonsolen, Streaming-Mediaplayer und digitale Bilderrahmen), und der Client nicht in der Lage ist, eingehende Anforderungen vom Autorisierungsserver zu empfangen.

Zum Beispiel kauft ein Kunde einen Roku, einen digitalen Bilderrahmen oder eine Spielkonsole. Der Kunde benötigt ein Zugriffstoken, um Filme, Bilder oder Spiele aus der Cloud abzurufen. Anstatt mit dem Streaming-Media-Player des Benutzers (z. B. einem Roku) oder einem digitalen Bilderrahmen zu interagieren, weist der Client den Benutzer an, einen anderen Computer oder ein anderes Gerät (einen Desktop-Computer, ein Smartphone oder ein Tablet) zu verwenden und eine Verbindung zum Autorisierungsserver herzustellen, um die Zugriffsanforderung zu genehmigen. Da der Client keine eingehenden Anforderungen empfangen kann, fragt er den Autorisierungsserver wiederholt ab, bis der Benutzer den Genehmigungsprozess abgeschlossen hat.

Das folgende Diagramm zeigt den Ablauf "Gerätecodezugriffsberechtigungstyp".

Ein Diagramm, das den Ablauf "Berechtigungstyp für Gerätecode" veranschaulicht.

In diesem OAuth-Ablauf:

Hinweis

Dieser Gerätefluss verwendet nicht das Client Secret, um den Gerätecode und den Benutzercode abzurufen. Das Client Secret wird beim Abrufen des Zugriffstokens verwendet (falls dem Client zugewiesen).

  1. Ein Geräteclient stellt eine nicht authentifizierte Anforderung an einen Endpunkt der Identitätsdomain /device. Das Gerät erhält einen Gerätecode, Benutzercode und eine Verifizierungs-URI.

    Der Geräteclient zeigt dem Benutzer den Benutzercode (user_code) an und stellt die URL (verification-uri) bereit, unter der der Benutzer den Benutzercode eingeben muss (nicht im Diagramm dargestellt).

  2. Der Geräteclient weiß nicht, ob der Benutzer autorisiert ist. Der Geräteclient fordert das Zugriffstoken wiederholt an (an oauth2/v1/token) im Hintergrund, bis der Benutzer den Benutzercode auf der Verifizierungsseite eingibt).

  3. Der Benutzer greift auf die Verifizierungsseite zu, meldet sich an und gibt dann den Benutzercode ein.

  4. Nachdem der Benutzer den Benutzercode eingegeben und den Zugriff autorisiert hat, wird vom OAuth-Server ein Zugriffstoken ausgegeben, und der Benutzer erhält über das Gerät Zugriff auf die geschützten Daten.

Funktion Verfügbar
Browserbasierte Endbenutzerinteraktion Ja
Kann einen externen Identitätsprovider für die Authentifizierung verwenden Ja
Aktualisierungstoken ist zulässig Ja

Siehe ein Beispiel für Beispiel für Autorisierungstyp "Gerätecodevergabe".

Beispiel für einen Autorisierungsablauf für den Berechtigungstyp "Gerätecode"

Der Berechtigungstyp "Gerätecode" bietet einen spezifischen Berechtigungsfluss, bei dem ein Geräteclient auf einem Gerät ausgeführt wird, das keine einfache Dateneingabemethode hat (z. B. Spielekonsolen, Streaming-Mediaplayer und digitale Bilderrahmen), und der Geräteclient nicht in der Lage ist, eingehende Anforderungen vom Autorisierungsserver zu empfangen.

Um ein Zugriffstoken für den Zugriff auf geschützte Ressourcen über einen Geräteclient zu erhalten, anstatt direkt mit dem Geräteclient zu interagieren, weist der Geräteclient den Benutzer an, einen anderen Computer oder ein anderes Gerät zu verwenden und eine Verbindung zum Autorisierungsserver herzustellen, um die Zugriffsanforderung zu genehmigen. Der Geräteclient fragt den Autorisierungsserver wiederholt ab, bis der Benutzer den Genehmigungsprozess abgeschlossen hat.

Wenn Sie eine Anwendung mit dem Berechtigungstyp "Gerätecode" in der Identitätsdomainkonsole erstellen, wählen Sie als Berechtigungstyp Gerätecode aus.

Weitere Informationen zum Device Code-Berechtigungstyp und einem Autorisierungsflussdiagramm finden Sie unter Device Code Grant Type.

Autorisierungsablauf

  1. Ein Geräteclient stellt eine nicht authentifizierte Anforderung an den /oauth2/v1/device-Endpunkt.

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

    Anforderungsbeispiel 

       curl -i -k 
   -H 'Authorization: application/x-www-form-urlencoded; charset=utf-8'
   --request POST 'https://<domainURL>/oauth2/v1/device'
   -d 'response_type=device_code&scope=http://example.com/quotes&client_id=<client-id>'

  2. Die Antwort enthält einen Gerätecode, Benutzercode und eine Verifizierungs-URI aus der OAuth-Clientanwendung.

    Antwortbeispiel 

    { 
"expires_in": 300, 
"device_code": "4d03f7bc-f7a5-4795-819a-5748c4801d35", 
"user_code": "SDFGHJKL",
"verification_uri": "http://<domainURL>/ui/v1/device" 
}

  3. Das Gerät zeigt den Benutzercode (user_code) an und stellt die URL (validation-uri) bereit, unter der der Benutzer den Benutzercode eingeben muss.

  4. Die Geräteclientanwendung weiß nicht, ob der Benutzer autorisiert ist. Während der Benutzer die Clientanforderung autorisiert (oder ablehnt), fragt der Client den Autorisierungsserver wiederholt am Tokenendpunkt (oauth2/v1/token) ab, um herauszufinden, ob der Benutzer den Benutzerautorisierungsschritt abgeschlossen hat. Der Client enthält den Verifizierungscode und seine Client-ID in der Anforderung.

    Anforderungsbeispiel: Vertraulicher Client

       curl -i -k 
   -H 'Authorization: application/x-www-form-urlencoded; charset=utf-8' 
   -H 'Authorization: Basic <base64 clientid:secret> 
   --request POST 'https://<domainURL>/oauth2/v1/token'
   -d 'grant_type=urn:ietf:params:oauth:grant-type:device_code&device_code=4d03f7bc-f7a5-4795-819a-5748c4801d35'

    Anforderungsbeispiel: Öffentlicher Client

       curl -i -k 
   -H 'Authorization: application/x-www-form-urlencoded; charset=utf-8' 
   --request POST 'https://<domainURL>/oauth2/v1/token'
   -d 'grant_type=urn:ietf:params:oauth:grant-type:device_code&client_id=3e51760ceb1245b7b77d0b1ff280bb72&device_code=4d03f7bc-f7a5-4795-819a-5748c4801d35'

    Anforderungsbeispiel mit einer Client-Assertion 

       curl -i -k 
   -H 'Authorization: application/x-www-form-urlencoded; charset=utf-8' 
   --request POST 'https://<domainURL>/oauth2/v1/token'
   -d 'grant_type=urn:ietf:params:oauth:grant-type:device_code&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=<clientAssertion>&device_code=4d03f7bc-f7a5-4795-819a-5748c4801d35'

    Anforderungsbeispiel mit einer SAML-Assertion

       curl -i -k 
   -H 'Authorization: application/x-www-form-urlencoded; charset=utf-8' 
   --request POST 'https://<domainURL>/oauth2/v1/token'
   -d 'grant_type=urn:ietf:params:oauth:grant-type:device_code&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Asaml2-bearer&client_assertion=<samlAssertion>&device_code=4d03f7bc-f7a5-4795-819a-5748c4801d35'

    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_'
  5. Nachdem der Benutzer den Benutzercode eingegeben und den Zugriff autorisiert hat, authentifiziert der OAuth-Autorisierungsserver den Benutzer und gibt ein Zugriffstoken zurück, das alle anwendbaren Geltungsbereiche basierend auf den Berechtigungen enthält, die von den Anwendungsrollen repräsentiert werden, die der anfordernden Clientanwendung erteilt wurden.
  6. Der anfordernde Geräteclient verwendet das Zugriffstoken in einem API-Aufruf, um geschützte Daten abzurufen.