Aller au contenu principal

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

Dernière mise à jour le