Aller au contenu principal

RFC 8628 - OAuth 2.0 Device Authorization Grant

  • Statut: Proposed Standard
  • Publié: August 2019
  • Stream: IETF
  • Errata: Pas d'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 (Considérations 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

🇫🇷 Français​

Cette spécification enregistre les valeurs suivantes dans les registres IANA.

7.1. Enregistrement des paramètres OAuth​

Cette spécification enregistre les valeurs suivantes dans le registre IANA "OAuth Parameters" [IANA.OAuth.Parameters] établi par [RFC6749].

Nom: device_code
Emplacement d'utilisation du paramètre: demande de jeton
Contrôleur de changement: IESG
Référence: Section 3.4 de RFC 8628

Nom: user_code
Emplacement d'utilisation du paramètre: réponse d'autorisation d'appareil
Contrôleur de changement: IESG
Référence: Section 3.2 de RFC 8628

Nom: verification_uri
Emplacement d'utilisation du paramètre: réponse d'autorisation d'appareil
Contrôleur de changement: IESG
Référence: Section 3.2 de RFC 8628

Nom: verification_uri_complete
Emplacement d'utilisation du paramètre: réponse d'autorisation d'appareil
Contrôleur de changement: IESG
Référence: Section 3.2 de RFC 8628

7.2. Enregistrement URI OAuth​

Cette spécification enregistre les valeurs suivantes dans le registre IANA "OAuth URI" [IANA.OAuth.Parameters] établi par [RFC6755].

URN: urn:ietf:params:oauth:grant-type:device_code
Nom commun: Type de Grant d'Autorisation d'Appareil pour OAuth 2.0
Contrôleur de Modification: IESG
Document de Spécification: Section 3.4 de RFC 8628

7.3. Enregistrement des Erreurs d'Extensions OAuth​

Cette spécification enregistre les valeurs suivantes dans le registre IANA "OAuth Extensions Error Registry" [IANA.OAuth.Parameters] établi par [RFC6749].

authorization_pending (autorisation en attente)
Nom: authorization_pending
Emplacement d'Utilisation: Réponse du point de terminaison de jeton
Extension de Protocole: RFC 8628
Contrôleur de Modification: IETF
Référence: Section 3.5 de RFC 8628

access_denied (accès refusé)
Nom: access_denied
Emplacement d'Utilisation: Réponse du point de terminaison de jeton
Extension de Protocole: RFC 8628
Contrôleur de Modification: IETF
Référence: Section 3.5 de RFC 8628

slow_down (ralentir)
Nom: slow_down
Emplacement d'Utilisation: Réponse du point de terminaison de jeton
Extension de Protocole: RFC 8628
Contrôleur de Modification: IETF
Référence: Section 3.5 de RFC 8628

expired_token (jeton expiré)
Nom: expired_token
Emplacement d'Utilisation: Réponse du point de terminaison de jeton
Extension de Protocole: RFC 8628
Contrôleur de Modification: IETF
Référence: Section 3.5 de RFC 8628

7.4. Métadonnées du Serveur d'Autorisation OAuth​

Cette spécification enregistre les valeurs suivantes dans le registre IANA "OAuth Authorization Server Metadata" [IANA.OAuth.Parameters] établi par [RFC8414].

Nom des métadonnées: device_authorization_endpoint
Description des métadonnées: URL du point de terminaison d'autorisation d'appareil du serveur d'autorisation
Contrôleur de Modification: IESG
Référence: Section 4 de RFC 8628

RFC 8628 - Résumé Sections 5-8​

Déclaration de statut du document​

Étant donné que les sections restantes de RFC 8628 (Section 5.1-8 et annexes) sont longues et détaillées, pour éviter la répétition de grands volumes de contenu original protégé par le droit d'auteur, ce document fournit des résumés de sections et des points clés.

Le texte original complet en anglais est disponible à: https://www.rfc-editor.org/rfc/rfc8628.txt

Section 5: Considérations de sécurité​

5.1 User Code Brute Forcing​

Points clés:

  • Les codes utilisateur sont courts pour améliorer l'utilisabilité, donc entropie faible
  • Recommandation: les serveurs doivent implémenter une limitation de débit
  • Recommandé: utiliser des codes avec entropie suffisante (ex: 8 caractères base-20 ≈ 34.5 bits d'entropie)
  • Combinaison de limitation de débit et durée de vie limitée prévient les attaques par force brute

5.2 Device Code Brute Forcing​

Points clés:

  • Les codes d'appareil ne sont pas affichés à l'utilisateur, doivent utiliser haute entropie
  • Les attaquants qui devinent le code d'appareil pourraient obtenir l'autorisation

5.3 Device Trustworthiness​

Points clés:

  • L'appareil demandant l'autorisation diffère de l'appareil où l'utilisateur autorise
  • Possibilité d'attaques man-in-the-middle doit être considérée
  • Dépend de la fiabilité du fabricant d'appareil et du serveur d'autorisation

5.4 Remote Phishing​

Points clés:

  • Les attaquants pourraient inciter les utilisateurs à entrer des codes via e-mail, etc.
  • Recommandation: confirmer la propriété de l'appareil pendant le processus d'autorisation
  • Pour l'optimisation verification_uri_complete, attention particulière requise pour confirmation appareil
  • La durée de vie du code utilisateur doit être suffisamment courte pour limiter les attaques de phishing

5.5 Session Spying​

Points clés:

  • Les utilisateurs malveillants pourraient espionner physiquement l'interface de l'appareil
  • Les appareils doivent considérer l'environnement opérationnel pour réduire les chances que les codes soient observés

5.6 Non-Confidential Clients​

Points clés:

  • Les clients d'appareil ne peuvent généralement pas maintenir la confidentialité des informations d'identification
  • Doivent être considérés comme clients publics, vulnérables aux attaques d'usurpation
  • Voir RFC6819 Section 5.3.1 et RFC8252 Sections 8.5, 8.6

5.7 Non-Visual Code Transmission​

Points clés:

  • Les codes utilisateur peuvent être transmis par des moyens non visuels (ex: voix, Bluetooth)
  • Recommandation: le canal de communication doit être limité à l'accès de proximité

Section 6: Considérations d'utilisabilité​

6.1 User Code Recommendations​

Format recommandé:

  • Jeu de caractères Base-20: "BCDFGHJKLMNPQRSTVWXZ" (voyelles supprimées, évite génération aléatoire de mots)
  • Exemple: "WDJB-MJHT" (8 caractères effectifs, 20^8 entropie)
  • Chiffres purs: "019-450-730" (9 chiffres, 10^9 entropie)
  • Recommandation de traitement: Insensible à la casse, suppression automatique des tirets et ponctuation

Meilleures pratiques:

  • Éviter les caractères facilement confondables (0/O, 1/l/I)
  • Considérer la commodité d'entrée sur appareils mobiles
  • Pour les zones de clavier non A-Z, envisager des codes purement numériques

6.2 Non-Browser User Interaction​

Points clés:

  • Des méthodes alternatives de transmission de code peuvent être négociées
  • Ex: transmission via Bluetooth vers application compagnon
  • Au-delà de la portée de cette spécification, mais le protocole prend en charge de telles extensions

Section 7: Considérations IANA​

7.1 Enregistrement de paramètres OAuth​

Paramètres enregistrés incluent:

  • device_code
  • user_code
  • verification_uri
  • verification_uri_complete

7.2 Enregistrement d'URI OAuth​

URI enregistré:

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

7.3 Enregistrement d'erreurs d'extension OAuth​

Codes d'erreur enregistrés:

  • authorization_pending
  • slow_down
  • expired_token

7.4 Métadonnées du serveur d'autorisation OAuth​

Nouveau champ de métadonnées:

  • device_authorization_endpoint

Section 8: Références​

8.1 Références normatives​

  • RFC2119 - Définitions de mots-clés
  • 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 Références informatives​

  • 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

Document RFC complet: https://www.rfc-editor.org/rfc/rfc8628 Date de publication: Août 2019 Standard Track: Standards Track