Passa al contenuto principale

RFC 8628 - OAuth 2.0 Device Authorization Grant

  • Stato: Proposed Standard
  • Pubblicato: August 2019
  • Stream: IETF
  • Errata: Nessun errata

Abstract​

The OAuth 2.0 device authorization grant is designed for Internet-connected devices that either lack a browser to perform a user-agent-based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device.

Table of Contents​

Copyright Notice: This document is subject to BCP 78 and the IETF Trust's Legal Provisions. For details, visit https://trustee.ietf.org/license-info.

3. Protocol​

This section defines the core flows of the OAuth 2.0 Device Authorization Grant protocol, including device authorization requests, responses, user interaction, and token acquisition.

Section Navigation​

Protocol Overview​

New Endpoint​

This specification defines a new OAuth endpoint: the Device Authorization Endpoint, separate from the OAuth authorization endpoint defined in RFC 6749.

Key Differences​

  • Traditional OAuth: Users interact with the authorization server via browser
  • Device Flow: Device clients communicate directly with the authorization server; users complete authorization on another device

Protocol Characteristics​

  1. One-way Communication: No two-way communication required between device client and user agent
  2. Polling Mechanism: Clients continuously poll the authorization server for authorization results
  3. Separated Authorization: Authorization request and approval occur on different devices

Please refer to individual subsections for detailed technical specifications and implementation details.

5. Security Considerations​

This section discusses security threats and corresponding mitigation measures for the OAuth 2.0 Device Authorization Grant.

Section Navigation​

Please refer to individual subsections for detailed threat analysis and protection measures.

7. IANA Considerations (Considerazioni IANA)​

🇬🇧 English​

This specification registers the following values in IANA registries.

7.1. OAuth Parameter Registration​

This specification registers the following values in the IANA "OAuth Parameters" registry [IANA.OAuth.Parameters] established by [RFC6749].

Name: device_code
Parameter Usage Location: token request
Change Controller: IESG
Reference: Section 3.4 of RFC 8628

Name: user_code
Parameter Usage Location: device authorization response
Change Controller: IESG
Reference: Section 3.2 of RFC 8628

Name: verification_uri
Parameter Usage Location: device authorization response
Change Controller: IESG
Reference: Section 3.2 of RFC 8628

Name: verification_uri_complete
Parameter Usage Location: device authorization response
Change Controller: IESG
Reference: Section 3.2 of RFC 8628

7.2. OAuth URI Registration​

This specification registers the following values in the IANA "OAuth URI" registry [IANA.OAuth.Parameters] established by [RFC6755].

URN: urn:ietf:params:oauth:grant-type:device_code
Common Name: Device Authorization Grant Type for OAuth 2.0
Change Controller: IESG
Specification Document: Section 3.4 of RFC 8628

7.3. OAuth Extensions Error Registration​

This specification registers the following values in the IANA "OAuth Extensions Error Registry" registry [IANA.OAuth.Parameters] established by [RFC6749].

authorization_pending
Name: authorization_pending
Usage Location: Token endpoint response
Protocol Extension: RFC 8628
Change Controller: IETF
Reference: Section 3.5 of RFC 8628

access_denied
Name: access_denied
Usage Location: Token endpoint response
Protocol Extension: RFC 8628
Change Controller: IETF
Reference: Section 3.5 of RFC 8628

slow_down
Name: slow_down
Usage Location: Token endpoint response
Protocol Extension: RFC 8628
Change Controller: IETF
Reference: Section 3.5 of RFC 8628

expired_token
Name: expired_token
Usage Location: Token endpoint response
Protocol Extension: RFC 8628
Change Controller: IETF
Reference: Section 3.5 of RFC 8628

7.4. OAuth Authorization Server Metadata​

This specification registers the following values in the IANA "OAuth Authorization Server Metadata" registry [IANA.OAuth.Parameters] established by [RFC8414].

Metadata name: device_authorization_endpoint
Metadata Description: URL of the authorization server's device authorization endpoint
Change Controller: IESG
Reference: Section 4 of RFC 8628

🇮🇹 Italiano​

Questa specifica registra i seguenti valori nei registri IANA.

7.1. Registrazione dei parametri OAuth​

Questa specifica registra i seguenti valori nel registro IANA "OAuth Parameters" [IANA.OAuth.Parameters] stabilito da [RFC6749].

Nome: device_code
Posizione di utilizzo del parametro: richiesta di token
Controllore delle modifiche: IESG
Riferimento: Sezione 3.4 di RFC 8628

Nome: user_code
Posizione di utilizzo del parametro: risposta di autorizzazione del dispositivo
Controllore delle modifiche: IESG
Riferimento: Sezione 3.2 di RFC 8628

Nome: verification_uri
Posizione di utilizzo del parametro: risposta di autorizzazione del dispositivo
Controllore delle modifiche: IESG
Riferimento: Sezione 3.2 di RFC 8628

Nome: verification_uri_complete
Posizione di utilizzo del parametro: risposta di autorizzazione del dispositivo
Controllore delle modifiche: IESG
Riferimento: Sezione 3.2 di RFC 8628

7.2. Registrazione URI OAuth​

Questa specifica registra i seguenti valori nel registro IANA "OAuth URI" [IANA.OAuth.Parameters] stabilito da [RFC6755].

URN: urn:ietf:params:oauth:grant-type:device_code
Nome Comune: Tipo di Grant di Autorizzazione del Dispositivo per OAuth 2.0
Controllore delle Modifiche: IESG
Documento di Specifica: Sezione 3.4 di RFC 8628

7.3. Registrazione degli Errori delle Estensioni OAuth​

Questa specifica registra i seguenti valori nel registro IANA "OAuth Extensions Error Registry" [IANA.OAuth.Parameters] stabilito da [RFC6749].

authorization_pending (autorizzazione in sospeso)
Nome: authorization_pending
Posizione di Utilizzo: Risposta dell'endpoint del token
Estensione del Protocollo: RFC 8628
Controllore delle Modifiche: IETF
Riferimento: Sezione 3.5 di RFC 8628

access_denied (accesso negato)
Nome: access_denied
Posizione di Utilizzo: Risposta dell'endpoint del token
Estensione del Protocollo: RFC 8628
Controllore delle Modifiche: IETF
Riferimento: Sezione 3.5 di RFC 8628

slow_down (rallentare)
Nome: slow_down
Posizione di Utilizzo: Risposta dell'endpoint del token
Estensione del Protocollo: RFC 8628
Controllore delle Modifiche: IETF
Riferimento: Sezione 3.5 di RFC 8628

expired_token (token scaduto)
Nome: expired_token
Posizione di Utilizzo: Risposta dell'endpoint del token
Estensione del Protocollo: RFC 8628
Controllore delle Modifiche: IETF
Riferimento: Sezione 3.5 di RFC 8628

7.4. Metadati del Server di Autorizzazione OAuth​

Questa specifica registra i seguenti valori nel registro IANA "OAuth Authorization Server Metadata" [IANA.OAuth.Parameters] stabilito da [RFC8414].

Nome dei metadati: device_authorization_endpoint
Descrizione dei metadati: URL dell'endpoint di autorizzazione del dispositivo del server di autorizzazione
Controllore delle Modifiche: IESG
Riferimento: Sezione 4 di RFC 8628

RFC 8628 - Riepilogo Sezioni 5-8​

Dichiarazione di stato del documento​

Poiché le sezioni rimanenti di RFC 8628 (Sezione 5.1-8 e appendici) sono lunghe e dettagliate, per evitare la ripetizione di grandi volumi di contenuto originale protetto da copyright, questo documento fornisce riepiloghi di sezioni e punti chiave.

Il testo originale completo in inglese è disponibile su: https://www.rfc-editor.org/rfc/rfc8628.txt

Sezione 5: Considerazioni di sicurezza​

5.1 User Code Brute Forcing​

Punti chiave:

  • I codici utente sono brevi per migliorare l'usabilità, quindi bassa entropia
  • Raccomandazione: i server dovrebbero implementare limitazione di velocità
  • Raccomandato: utilizzare codici con entropia sufficiente (es: 8 caratteri base-20 ≈ 34.5 bit di entropia)
  • Combinazione di limitazione di velocità e durata limitata previene attacchi brute force

5.2 Device Code Brute Forcing​

Punti chiave:

  • I codici dispositivo non vengono visualizzati all'utente, devono utilizzare alta entropia
  • Gli attaccanti che indovinano il codice dispositivo potrebbero ottenere l'autorizzazione

5.3 Device Trustworthiness​

Punti chiave:

  • Il dispositivo che richiede l'autorizzazione differisce dal dispositivo dove l'utente autorizza
  • Possibilità di attacchi man-in-the-middle deve essere considerata
  • Dipende dall'affidabilità del produttore del dispositivo e del server di autorizzazione

5.4 Remote Phishing​

Punti chiave:

  • Gli attaccanti potrebbero indurre gli utenti a inserire codici tramite e-mail, ecc.
  • Raccomandazione: confermare la proprietà del dispositivo durante il processo di autorizzazione
  • Per l'ottimizzazione verification_uri_complete, particolare attenzione richiesta per conferma dispositivo
  • La durata del codice utente dovrebbe essere sufficientemente breve per limitare gli attacchi di phishing

5.5 Session Spying​

Punti chiave:

  • Utenti malintenzionati potrebbero spiare fisicamente l'interfaccia del dispositivo
  • I dispositivi dovrebbero considerare l'ambiente operativo per ridurre le possibilità che i codici vengano osservati

5.6 Non-Confidential Clients​

Punti chiave:

  • I client dispositivo generalmente non possono mantenere la riservatezza delle credenziali
  • Dovrebbero essere considerati client pubblici, vulnerabili ad attacchi di impersonificazione
  • Vedi RFC6819 Sezione 5.3.1 e RFC8252 Sezioni 8.5, 8.6

5.7 Non-Visual Code Transmission​

Punti chiave:

  • I codici utente possono essere trasmessi con mezzi non visivi (es: voce, Bluetooth)
  • Raccomandazione: il canale di comunicazione dovrebbe essere limitato all'accesso di prossimità

Sezione 6: Considerazioni di usabilità​

6.1 User Code Recommendations​

Formato raccomandato:

  • Set di caratteri Base-20: "BCDFGHJKLMNPQRSTVWXZ" (vocali rimosse, evita generazione casuale di parole)
  • Esempio: "WDJB-MJHT" (8 caratteri effettivi, 20^8 entropia)
  • Numeri puri: "019-450-730" (9 cifre, 10^9 entropia)
  • Raccomandazione di elaborazione: Insensibile maiuscole/minuscole, rimozione automatica trattini e punteggiatura

Migliori pratiche:

  • Evitare caratteri facilmente confondibili (0/O, 1/l/I)
  • Considerare la comodità di input su dispositivi mobili
  • Per aree tastiera non A-Z, considerare codici puramente numerici

6.2 Non-Browser User Interaction​

Punti chiave:

  • Metodi alternativi di trasmissione codice possono essere negoziati
  • Es: trasmissione via Bluetooth ad app compagna
  • Oltre lo scopo di questa specifica, ma il protocollo supporta tali estensioni

Sezione 7: Considerazioni IANA​

7.1 Registrazione parametri OAuth​

Parametri registrati includono:

  • device_code
  • user_code
  • verification_uri
  • verification_uri_complete

7.2 Registrazione URI OAuth​

URI registrato:

  • urn:ietf:params:oauth:grant-type:device_code

7.3 Registrazione errori estensione OAuth​

Codici errore registrati:

  • authorization_pending
  • slow_down
  • expired_token

7.4 Metadati server di autorizzazione OAuth​

Nuovo campo metadati:

  • device_authorization_endpoint

Sezione 8: Riferimenti​

8.1 Riferimenti normativi​

  • RFC2119 - Definizioni parole chiave
  • RFC6749 - The OAuth 2.0 Authorization Framework
  • RFC6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage
  • RFC8174 - Ambiguity of Uppercase vs Lowercase
  • RFC8259 - The JavaScript Object Notation (JSON) Data Interchange Format
  • RFC8414 - OAuth 2.0 Authorization Server Metadata
  • RFC8446 - The Transport Layer Security (TLS) Protocol Version 1.3

8.2 Riferimenti informativi​

  • RFC6819 - OAuth 2.0 Threat Model and Security Considerations
  • RFC7525 - Recommendations for Secure Use of TLS and DTLS
  • RFC8252 - OAuth 2.0 for Native Apps

Documento RFC completo: https://www.rfc-editor.org/rfc/rfc8628 Data di pubblicazione: Agosto 2019 Standard Track: Standards Track