3.4. Device Access Token Request (Geräte-Zugriffstoken-Anfrage)

Nachdem dem Benutzer Anweisungen angezeigt wurden, erstellt der Client eine Zugriffstokenanfrage und sendet sie an den Token-Endpunkt (wie in Abschnitt 3.2 von [RFC6749] definiert) mit einem "grant_type" von "urn:ietf:params:oauth:grant-type:device_code". Dies ist ein Erweiterungsgenehmigungstyp (wie in Abschnitt 4.5 von [RFC6749] definiert), der durch diese Spezifikation erstellt wurde, mit den folgenden Parametern:

grant_type (Genehmigungstyp)

• ERFORDERLICH. Der Wert MUSS auf "urn:ietf:params:oauth:grant-type:device_code" gesetzt werden.

device_code (Gerätecode)

• ERFORDERLICH. Der Geräteverifizierungscode "device_code" aus der Geräteautorisierungsantwort, definiert in Abschnitt 3.2.

client_id (Client-Identifikator)

• ERFORDERLICH, wenn der Client sich nicht beim Autorisierungsserver authentifiziert, wie in Abschnitt 3.2.1. von [RFC6749] beschrieben. Der Client-Identifikator, wie in Abschnitt 2.2 von [RFC6749] beschrieben.

Zum Beispiel stellt der Client die folgende HTTPS-Anfrage (Zeilenumbrüche dienen nur der Anzeige):

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code
&device_code=GmRhmhcxhwAzkoEqiMEg_DnyEysNkuNhszIySk9eS
&client_id=1406020730

Wenn dem Client Client-Anmeldeinformationen ausgestellt wurden (oder andere Authentifizierungsanforderungen zugewiesen wurden), MUSS sich der Client beim Autorisierungsserver authentifizieren, wie in Abschnitt 3.2.1 von [RFC6749] beschrieben. Beachten Sie, dass statisch verteilte Client-Anmeldeinformationen Sicherheitsauswirkungen haben; siehe Abschnitt 5.6.

Die Antwort auf diese Anfrage ist in Abschnitt 3.5 definiert. Im Gegensatz zu anderen OAuth-Genehmigungstypen wird erwartet, dass der Client die Zugriffstokenanfrage basierend auf dem Fehlercode in der Antwort wiederholt in einem Polling-Modus versucht.