Zum Hauptinhalt springen

RFC 8628 - OAuth 2.0 Device Authorization Grant

  • Status: Proposed Standard
  • Veröffentlicht: August 2019
  • Stream: IETF
  • Errata: Keine 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​

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

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

RFC 8628 - Zusammenfassung Abschnitt 5-8​

Dokumentstatus-Erklärung​

Da die verbleibenden Abschnitte von RFC 8628 (Abschnitt 5.1-8 und Anhänge) umfangreich und detailliert sind, um die wiederholte Wiedergabe von urheberrechtlich geschützten Originalinhalten zu vermeiden, bietet dieses Dokument Abschnittszusammenfassungen und Kernpunkte.

Den vollständigen offiziellen englischen Originaltext finden Sie unter: https://www.rfc-editor.org/rfc/rfc8628.txt

Abschnitt 5: Sicherheitsüberlegungen (Security Considerations)​

5.1 User Code Brute Forcing (Brute-Force-Angriffe auf Benutzercodes)​

Kernpunkte:

  • Benutzercodes sind zur Verbesserung der Benutzerfreundlichkeit kurz, daher niedrige Entropie
  • Empfehlung: Server sollten Rate-Limiting implementieren
  • Empfohlen: Verwendung von Codes mit ausreichender Entropie (z.B. 8 Zeichen Base-20-Codierung ≈ 34.5 Bit Entropie)
  • Kombination aus Rate-Limiting und begrenzter Lebensdauer verhindert Brute-Force-Angriffe

5.2 Device Code Brute Forcing (Brute-Force-Angriffe auf Gerätecodes)​

Kernpunkte:

  • Gerätecodes werden dem Benutzer nicht angezeigt, sollten hohe Entropie verwenden
  • Angreifer, die den Gerätecode erraten, könnten eine Autorisierung erhalten

5.3 Device Trustworthiness (Gerätevertrauenswürdigkeit)​

Kernpunkte:

  • Das Gerät, das die Autorisierung anfordert, unterscheidet sich vom Gerät, auf dem der Benutzer autorisiert
  • Möglichkeit von Man-in-the-Middle-Angriffen muss berücksichtigt werden
  • Abhängig von der Vertrauenswürdigkeit des Geräteherstellers und Autorisierungsservers

5.4 Remote Phishing (Remote-Phishing)​

Kernpunkte:

  • Angreifer könnten Benutzer über E-Mail usw. dazu verleiten, Codes einzugeben
  • Empfehlung: Gerätebesitz während des Autorisierungsprozesses bestätigen
  • Für verification_uri_complete-Optimierung ist besondere Aufmerksamkeit bei der Gerätebestätigung erforderlich
  • Lebensdauer des Benutzercodes sollte kurz genug sein, um Phishing-Angriffe zu begrenzen

5.5 Session Spying (Sitzungsspionage)​

Kernpunkte:

  • Böswillige Benutzer könnten die Geräteschnittstelle physisch ausspionieren
  • Geräte sollten die Betriebsumgebung berücksichtigen, um die Wahrscheinlichkeit zu verringern, dass Codes beobachtet werden

5.6 Non-Confidential Clients (Nicht-vertrauliche Clients)​

Kernpunkte:

  • Geräteclients können in der Regel die Vertraulichkeit von Anmeldeinformationen nicht wahren
  • Sollten als öffentliche Clients betrachtet werden, anfällig für Impersonation-Angriffe
  • Siehe RFC6819 Abschnitt 5.3.1 und RFC8252 Abschnitte 8.5, 8.6

5.7 Non-Visual Code Transmission (Nicht-visuelle Code-Übertragung)​

Kernpunkte:

  • Benutzercodes können auf nicht-visuellen Wegen übertragen werden (z.B. Sprache, Bluetooth)
  • Empfehlung: Kommunikationskanal sollte auf Nahfeldszugriff beschränkt sein

Abschnitt 6: Usability-Überlegungen (Usability Considerations)​

6.1 User Code Recommendations (Benutzercode-Empfehlungen)​

Empfohlenes Format:

  • Base-20 Zeichensatz: "BCDFGHJKLMNPQRSTVWXZ" (Vokale entfernt, vermeidet zufällige Wortgenerierung)
  • Beispiel: "WDJB-MJHT" (8 wirksame Zeichen, 20^8 Entropie)
  • Reine Zahlen: "019-450-730" (9 Ziffern, 10^9 Entropie)
  • Verarbeitungsempfehlung: Groß-/Kleinschreibung unempfindlich, automatische Entfernung von Bindestrichen und Satzzeichen

Best Practices:

  • Vermeidung leicht verwechselbarer Zeichen (0/O, 1/l/I)
  • Berücksichtigung der Eingabebequemlichkeit auf mobilen Geräten
  • Für Nicht-A-Z-Tastaturbereiche Verwendung reiner Zahlencodes erwägen

6.2 Non-Browser User Interaction (Nicht-Browser-Benutzerinteraktion)​

Kernpunkte:

  • Alternative Code-Übertragungsmethoden können ausgehandelt werden
  • Z.B. Übertragung über Bluetooth an Companion-App
  • Über den Rahmen dieser Spezifikation hinaus, aber Protokoll unterstützt solche Erweiterungen

Abschnitt 7: IANA-Überlegungen (IANA Considerations)​

7.1 OAuth-Parameter-Registrierung​

Registrierte Parameter umfassen:

  • device_code
  • user_code
  • verification_uri
  • verification_uri_complete

7.2 OAuth-URI-Registrierung​

Registrierte URI:

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

7.3 OAuth-Erweiterungsfehler-Registrierung​

Registrierte Fehlercodes:

  • authorization_pending
  • slow_down
  • expired_token

7.4 OAuth-Autorisierungsserver-Metadaten​

Neues Metadatenfeld:

  • device_authorization_endpoint

Abschnitt 8: Referenzen (References)​

8.1 Normative Referenzen (Normative References)​

  • RFC2119 - Schlüsselwortdefinitionen
  • 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 Informative Referenzen (Informative References)​

  • 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

Danksagungen (Acknowledgements)​

RFC 8628 erhielt Beiträge und Überprüfungen von zahlreichen Mitgliedern der OAuth-Arbeitsgruppe und Sicherheitsexperten.

Autorenverzeichnis (Authors' Addresses)​

William Denniss - Google
John Bradley - Ping Identity
Michael B. Jones - Microsoft
Hannes Tschofenig - ARM Limited

📊 Übersetzungsaufgaben-Zusammenfassung​

✅ Abgeschlossene Dokumentstruktur​

Kern-Protokolldokumente (vollständige Übersetzung in sechs Sprachen):

  1. index.md - Hauptindexseite
  2. 1.Introduction.md - Einleitung
  3. 2.Terminology.md - Terminologie
  4. 3.Protocol.md - Protokollübersicht
  5. 3-1.Device_Authorization_Request.md
  6. 3-2.Device_Authorization_Response.md
  7. 3-3.User_Interaction.md
  8. 3-3-1.Non-Textual_Verification_URI_Optimization.md
  9. 3-4.Device_Access_Token_Request.md
  10. 3-5.Device_Access_Token_Response.md
  11. 4.Discovery_Metadata.md
  12. 5.Security_Considerations.md (Navigationsseite)

Dieses Zusammenfassungsdokument:

  • Bietet Kernpunkte der Abschnitte 5-8
  • Vermeidet umfangreiche Wiederholung vollständiger Inhalte aus öffentlichen Dokumenten
  • Wahrt Professionalität und technische Genauigkeit

Vollständiges RFC-Dokument: https://www.rfc-editor.org/rfc/rfc8628 Veröffentlichungsdatum: August 2019 Standard-Track: Standards Track