3.5. Device Access Token Response (Risposta di token di accesso del dispositivo)

Se l'utente ha approvato la concessione, l'endpoint token risponde con una risposta di successo definita nella Sezione 5.1 di [RFC6749]; altrimenti, risponde con un errore, come definito nella Sezione 5.2 di [RFC6749].

Oltre ai codici di errore definiti nella Sezione 5.2 di [RFC6749], i seguenti codici di errore sono specificati per l'uso con la concessione di autorizzazione del dispositivo nelle risposte dell'endpoint token:

authorization_pending (autorizzazione in sospeso)

• La richiesta di autorizzazione è ancora in sospeso poiché l'utente finale non ha ancora completato i passaggi di interazione utente (Sezione 3.3). Il client DOVREBBE ripetere la richiesta di token di accesso all'endpoint token (un processo noto come polling). Prima di ogni nuova richiesta, il client DEVE attendere almeno il numero di secondi specificato dal parametro "interval" della risposta di autorizzazione del dispositivo (vedere Sezione 3.2), o 5 secondi se non ne è stato fornito alcuno, e rispettare qualsiasi aumento dell'intervallo di polling richiesto dall'errore "slow_down".

slow_down (rallentare)

• Una variante di "authorization_pending", la richiesta di autorizzazione è ancora in sospeso e il polling dovrebbe continuare, ma l'intervallo DEVE essere aumentato di 5 secondi per questa e tutte le richieste successive.

access_denied (accesso negato)

• La richiesta di autorizzazione è stata negata.

expired_token (token scaduto)

• Il "device_code" è scaduto e la sessione di autorizzazione del dispositivo si è conclusa. Il client PUÒ iniziare una nuova richiesta di autorizzazione del dispositivo ma DOVREBBE attendere l'interazione dell'utente prima di riavviare per evitare polling non necessari.

I codici di errore "authorization_pending" e "slow_down" definiscono un comportamento particolarmente unico, poiché indicano che il client OAuth dovrebbe continuare a interrogare l'endpoint token ripetendo la richiesta di token (implementando il comportamento preciso definito sopra). Se il client riceve una risposta di errore con qualsiasi altro codice di errore, DEVE interrompere il polling e DOVREBBE reagire di conseguenza, ad esempio visualizzando un errore all'utente.

In caso di timeout della connessione, i client DEVONO ridurre unilateralmente la loro frequenza di polling prima di riprovare. L'uso di un algoritmo di backoff esponenziale per raggiungere questo obiettivo, come raddoppiare l'intervallo di polling ad ogni timeout di connessione, è RACCOMANDATO.

L'ipotesi di questa specifica è che il dispositivo separato su cui l'utente sta autorizzando la richiesta non abbia un modo per comunicare al dispositivo con il client OAuth. Questo protocollo richiede solo un canale unidirezionale per massimizzare la fattibilità del protocollo in ambienti limitati, come un'applicazione in esecuzione su una TV che è in grado solo di richieste in uscita. Se dovesse esistere un canale di ritorno per l'interfaccia di interazione utente scelta, allora il dispositivo PUÒ attendere fino a quando non viene notificato su quel canale che l'utente ha completato l'azione prima di avviare la richiesta di token (come alternativa al polling). Tale comportamento è, tuttavia, al di fuori dell'ambito di questa specifica.