3.5. Device Access Token Response (Geräte-Zugriffstoken-Antwort)

Wenn der Benutzer die Genehmigung erteilt hat, antwortet der Token-Endpunkt mit einer Erfolgsantwort, die in Abschnitt 5.1 von [RFC6749] definiert ist; andernfalls antwortet er mit einem Fehler, wie in Abschnitt 5.2 von [RFC6749] definiert.

Zusätzlich zu den in Abschnitt 5.2 von [RFC6749] definierten Fehlercodes sind die folgenden Fehlercodes für die Verwendung mit der Geräteautorisierungsgenehmigung in Token-Endpunkt-Antworten spezifiziert:

authorization_pending (Autorisierung ausstehend)

• Die Autorisierungsanfrage steht noch aus, da der Endbenutzer die Benutzerinteraktionsschritte (Abschnitt 3.3) noch nicht abgeschlossen hat. Der Client SOLLTE die Zugriffstokenanfrage an den Token-Endpunkt wiederholen (ein als Polling bekannter Prozess). Vor jeder neuen Anfrage MUSS der Client mindestens die Anzahl von Sekunden warten, die durch den "interval"-Parameter der Geräteautorisierungsantwort angegeben ist (siehe Abschnitt 3.2), oder 5 Sekunden, wenn keiner angegeben wurde, und jede Erhöhung des Polling-Intervalls beachten, die durch den "slow_down"-Fehler erforderlich ist.

slow_down (verlangsamen)

• Eine Variante von "authorization_pending". Die Autorisierungsanfrage steht noch aus und das Polling sollte fortgesetzt werden, aber das Intervall MUSS für diese und alle nachfolgenden Anfragen um 5 Sekunden erhöht werden.

access_denied (Zugriff verweigert)

• Die Autorisierungsanfrage wurde abgelehnt.

expired_token (Token abgelaufen)

• Der "device_code" ist abgelaufen und die Geräteautorisierungssitzung wurde beendet. Der Client KANN eine neue Geräteautorisierungsanfrage starten, SOLLTE jedoch vor dem Neustart auf Benutzerinteraktion warten, um unnötiges Polling zu vermeiden.

Die Fehlercodes "authorization_pending" und "slow_down" definieren ein besonders einzigartiges Verhalten, da sie anzeigen, dass der OAuth-Client weiterhin den Token-Endpunkt abfragen sollte, indem er die Tokenanfrage wiederholt (wobei das oben definierte präzise Verhalten implementiert wird). Wenn der Client eine Fehlerantwort mit einem anderen Fehlercode erhält, MUSS er das Polling stoppen und SOLLTE entsprechend reagieren, z.B. durch Anzeige eines Fehlers an den Benutzer.

Bei einer Verbindungszeitüberschreitung MÜSSEN Clients ihre Polling-Frequenz einseitig reduzieren, bevor sie es erneut versuchen. Die Verwendung eines exponentiellen Backoff-Algorithmus, um dies zu erreichen, wie z.B. die Verdoppelung des Polling-Intervalls bei jeder solchen Verbindungszeitüberschreitung, wird EMPFOHLEN.

Die Annahme dieser Spezifikation ist, dass das separate Gerät, auf dem der Benutzer die Anfrage autorisiert, keine Möglichkeit hat, mit dem Gerät mit dem OAuth-Client zu kommunizieren. Dieses Protokoll erfordert nur einen Einwegkanal, um die Durchführbarkeit des Protokolls in eingeschränkten Umgebungen zu maximieren, wie z.B. eine auf einem Fernseher laufende Anwendung, die nur zu ausgehenden Anfragen fähig ist. Wenn ein Rückkanal für die gewählte Benutzerinteraktionsschnittstelle existieren würde, KANN das Gerät warten, bis es über diesen Kanal benachrichtigt wird, dass der Benutzer die Aktion abgeschlossen hat, bevor es die Tokenanfrage initiiert (als Alternative zum Polling). Ein solches Verhalten liegt jedoch außerhalb des Anwendungsbereichs dieser Spezifikation.