3.5. Device Access Token Response (Réponse de jeton d'accès d'appareil)

Si l'utilisateur a approuvé l'autorisation, le point de terminaison de jeton répond avec une réponse de succès définie dans la Section 5.1 de [RFC6749]; sinon, il répond avec une erreur, comme défini dans la Section 5.2 de [RFC6749].

En plus des codes d'erreur définis dans la Section 5.2 de [RFC6749], les codes d'erreur suivants sont spécifiés pour une utilisation avec l'autorisation d'appareil dans les réponses du point de terminaison de jeton:

authorization_pending (autorisation en attente)

• La demande d'autorisation est toujours en attente car l'utilisateur final n'a pas encore terminé les étapes d'interaction utilisateur (Section 3.3). Le client DEVRAIT répéter la demande de jeton d'accès au point de terminaison de jeton (un processus connu sous le nom de sondage). Avant chaque nouvelle demande, le client DOIT attendre au moins le nombre de secondes spécifié par le paramètre "interval" de la réponse d'autorisation de l'appareil (voir Section 3.2), ou 5 secondes si aucun n'a été fourni, et respecter toute augmentation de l'intervalle de sondage requise par l'erreur "slow_down".

slow_down (ralentir)

• Une variante de "authorization_pending", la demande d'autorisation est toujours en attente et le sondage devrait continuer, mais l'intervalle DOIT être augmenté de 5 secondes pour cette demande et toutes les demandes ultérieures.

access_denied (accès refusé)

• La demande d'autorisation a été refusée.

expired_token (jeton expiré)

• Le "device_code" a expiré et la session d'autorisation de l'appareil s'est terminée. Le client PEUT commencer une nouvelle demande d'autorisation d'appareil mais DEVRAIT attendre l'interaction de l'utilisateur avant de redémarrer pour éviter un sondage inutile.

Les codes d'erreur "authorization_pending" et "slow_down" définissent un comportement particulièrement unique, car ils indiquent que le client OAuth devrait continuer à sonder le point de terminaison de jeton en répétant la demande de jeton (en mettant en œuvre le comportement précis défini ci-dessus). Si le client reçoit une réponse d'erreur avec tout autre code d'erreur, il DOIT arrêter le sondage et DEVRAIT réagir en conséquence, par exemple en affichant une erreur à l'utilisateur.

En cas de délai d'attente de connexion, les clients DOIVENT réduire unilatéralement leur fréquence de sondage avant de réessayer. L'utilisation d'un algorithme de backoff exponentiel pour y parvenir, tel que doubler l'intervalle de sondage à chaque délai d'attente de connexion, est RECOMMANDÉE.

L'hypothèse de cette spécification est que l'appareil séparé sur lequel l'utilisateur autorise la demande n'a pas de moyen de communiquer avec l'appareil avec le client OAuth. Ce protocole ne nécessite qu'un canal unidirectionnel afin de maximiser la viabilité du protocole dans des environnements restreints, comme une application fonctionnant sur une télévision qui n'est capable que de demandes sortantes. Si un canal de retour devait exister pour l'interface d'interaction utilisateur choisie, alors l'appareil PEUT attendre d'être notifié sur ce canal que l'utilisateur a terminé l'action avant d'initier la demande de jeton (comme alternative au sondage). Un tel comportement est toutefois en dehors de la portée de cette spécification.