Auf dieser Seite

QOAuth2DeviceAuthorizationFlow Class

Die Klasse „QOAuth2DeviceAuthorizationFlow“ bietet eine Implementierung des „Device Authorization Grant “-Ablaufs. Mehr...

Header: #include <QOAuth2DeviceAuthorizationFlow>
CMake: find_package(Qt6 REQUIRED COMPONENTS NetworkAuth)
target_link_libraries(mytarget PRIVATE Qt6::NetworkAuth)
qmake: QT += networkauth
Seit: Qt 6.9
Erbt von: QAbstractOAuth2

Eigenschaften

Öffentliche Funktionen

QOAuth2DeviceAuthorizationFlow()
QOAuth2DeviceAuthorizationFlow(QObject *parent)
QOAuth2DeviceAuthorizationFlow(QNetworkAccessManager *manager, QObject *parent = nullptr)
virtual ~QOAuth2DeviceAuthorizationFlow() override
QUrl completeVerificationUrl() const
bool isPolling() const
QString userCode() const
QDateTime userCodeExpirationAt() const
QUrl verificationUrl() const

Öffentliche Slots

virtual void grant() override
bool startTokenPolling()
void stopTokenPolling()

Signale

void authorizeWithUserCode(const QUrl &verificationUrl, const QString &userCode, const QUrl &completeVerificationUrl)
void completeVerificationUrlChanged(const QUrl &completeVerificationUrl)
void pollingChanged(bool polling)
void userCodeChanged(const QString &userCode)
void userCodeExpirationAtChanged(const QDateTime &expiration)
void verificationUrlChanged(const QUrl &verificationUrl)

Geschützte Slots

(since 6.9) void refreshTokensImplementation()

Ausführliche Beschreibung

Diese Klasse implementiert den „Device Authorization Grant“-Ablauf, der zum Abrufen und Aktualisieren von Zugriffstoken und ID-Token dient, insbesondere auf Geräten ohne User-Agent oder mit eingeschränkten Eingabemöglichkeiten. Zu diesen Geräten zählen Fernseher, Maschinen-HMIs, Haushaltsgeräte und IoT-Geräte.

Der Geräte-Ablauf kann auf jeder Plattform und jedem Betriebssystem verwendet werden, das SSL/TLS-Anfragen unterstützt. Im Gegensatz zu „ QOAuth2AuthorizationCodeFlow “ basiert dieser Ablauf nicht auf Weiterleitungen und verwendet daher kein „ reply handler “.

Verwendung des Device Flow

Die folgenden Codeausschnitte veranschaulichen die typische Verwendung. Zunächst richten wir den Ablauf ähnlich wie bei „ QOAuth2AuthorizationCodeFlow “ ein:

m_deviceFlow.setAuthorizationUrl(QUrl(authorizationUrl));
m_deviceFlow.setTokenUrl(QUrl(accessTokenUrl));
m_deviceFlow.setRequestedScopeTokens({scope});
m_deviceFlow.setClientIdentifier(clientIdentifier);
// The need for a client secret depends on the authorization server
m_deviceFlow.setClientIdentifierSharedKey(clientSecret);

Anschließend verbinden wir uns mit dem Signal „ authorizeWithUserCode “, um die Benutzerautorisierung abzuwickeln:

connect(&m_deviceFlow, &QOAuth2DeviceAuthorizationFlow::authorizeWithUserCode, this,
    [](const QUrl&verificationUrl, const QString&userCode, const QUrl&completeVerificationUrl) {
        if (completeVerificationUrl.isValid()) {
            // Wenn der Autorisierungsserver eine vollständige URL bereitgestellt hat,
            // die die erforderlichen Daten bereits als Teil der URL-Parameter enthält,
            // können Sie diese verwenden
            qDebug() << "Complete verification uri:" << completeVerificationUrl;
        } else {
            // Der Autorisierungsserver hat nur eine Verifizierungs-URL bereitgestellt; diese verwenden
            qDebug() << "Verification uri and usercode:" << verificationUrl << userCode;
        }
    }
);

Dieser Teil ist entscheidend für den Ablauf, und wie Sie damit umgehen, hängt von Ihrem konkreten Anwendungsfall ab. So oder so muss der Benutzer die Autorisierung abschließen.

Der Geräteablauf legt nicht fest, wie dieser Autorisierungsvorgang abgeschlossen wird, wodurch er für verschiedene Anwendungsfälle flexibel einsetzbar ist. Dies kann erreicht werden, indem dem Nutzer die Verifizierungs-URI und der Nutzercode angezeigt werden, woraufhin er auf einem anderen Gerät dorthin navigieren kann. Alternativ könnten Sie dem Nutzer einen QR-Code anzeigen, den er mit seinem Mobilgerät scannen kann, an eine Begleit-App senden, per E-Mail an den Nutzer versenden und so weiter.

Während die Autorisierung noch aussteht, fragt „ QOAuth2DeviceAuthorizationFlow “ den Server in bestimmten Intervallen (in der Regel alle 5 Sekunden) ab, bis der Nutzer die Autorisierung akzeptiert oder ablehnt; daraufhin antwortet der Server entsprechend und der Ablauf wird abgeschlossen.

Fehler können wie folgt erkannt werden:

connect(&m_deviceFlow, &QAbstractOAuth::requestFailed, this, [](QAbstractOAuth::Error error) {
    Q_UNUSED(error);
    // Handle error
});

connect(&m_deviceFlow, &QAbstractOAuth2::serverReportedErrorOccurred, this,
    [](const QString &error, const QString &errorDescription, const QUrl &uri) {
        // Check server reported error details if needed
        Q_UNUSED(error);
        Q_UNUSED(errorDescription);
        Q_UNUSED(uri);
    }
);

QAbstractOAuth2::serverReportedErrorOccurredMit dem Signal () lassen sich Informationen zu bestimmten, in RFC definierten Fehlern abrufen. Im Gegensatz zu QAbstractOAuth::requestFailed() deckt es jedoch keine Fehler wie Netzwerkfehler oder Fehler in der Client-Konfiguration ab.

Der Abschluss eines Flusses wird ähnlich wie bei ` QOAuth2AuthorizationCodeFlow` erkannt, zum Beispiel:

connect(&m_deviceFlow, &QAbstractOAuth::granted, this, [this](){
    // Here we use QNetworkRequestFactory to store the access token
    m_api.setBearerToken(m_deviceFlow.token().toLatin1());
});
m_deviceFlow.grant();

Dokumentation zu Eigenschaften

[read-only] completeVerificationUrl : QUrl

Diese Eigenschaft enthält eine URL, über die der Benutzer die Autorisierung abschließen kann. Die URL selbst enthält den Code „ user_code “ und erspart dem Benutzer somit die manuelle Eingabe des Codes. Die Unterstützung dieser vollständigen URL variiert je nach Autorisierungsserver.

Zugriffsfunktionen:

QUrl completeVerificationUrl() const

Benachrichtigungssignal:

void completeVerificationUrlChanged(const QUrl &completeVerificationUrl)

Siehe auch „ verificationUrl “ und „ Device Flow Usage “.

[read-only] polling : bool

Diese Eigenschaft gibt an, ob der Flow aktiv nach Tokens abfragt oder nicht.

Zugriffsfunktionen:

bool isPolling() const

Notifier-Signal:

void pollingChanged(bool polling)

Siehe auch „ startTokenPolling()“ und „ stopTokenPolling()“.

[read-only] userCode : QString

Diese Eigenschaft enthält den in der Autorisierungsantwort erhaltenen user_code. Dieser Code wird vom Benutzer verwendet, um die Autorisierung abzuschließen.

Zugriffsfunktionen:

QString userCode() const

Benachrichtigungssignal:

void userCodeChanged(const QString &userCode)

Siehe auch verificationUrl, completeVerificationUrl und Device Flow Usage.

[read-only] userCodeExpirationAt : QDateTime

Diese Eigenschaft enthält die Ortszeit, zu der der Benutzercode und die zugehörigen Gerätecodes ablaufen. Die Codes sind in der Regel zwischen 5 und 30 Minuten gültig.

Zugriffsfunktionen:

QDateTime userCodeExpirationAt() const

Benachrichtigungssignal:

void userCodeExpirationAtChanged(const QDateTime &expiration)

Siehe auch „ userCode “.

[read-only] verificationUrl : QUrl

Diese Eigenschaft enthält die URL, unter der der Benutzer den Benutzercode eingeben muss, um die Autorisierung abzuschließen.

Zugriffsfunktionen:

QUrl verificationUrl() const

Benachrichtigungssignal:

void verificationUrlChanged(const QUrl &verificationUrl)

Siehe auch „ userCode “, „ completeVerificationUrl “ und „ Device Flow Usage “.

Dokumentation der Member-Funktionen

QOAuth2DeviceAuthorizationFlow::QOAuth2DeviceAuthorizationFlow()

Erstellt ein QOAuth2DeviceAuthorizationFlow-Objekt.

[explicit] QOAuth2DeviceAuthorizationFlow::QOAuth2DeviceAuthorizationFlow(QObject *parent)

Erstellt ein `QOAuth2DeviceAuthorizationFlow`-Objekt mit dem übergeordneten Objekt ` parent`.

[explicit] QOAuth2DeviceAuthorizationFlow::QOAuth2DeviceAuthorizationFlow(QNetworkAccessManager *manager, QObject *parent = nullptr)

Erstellt ein `QOAuth2DeviceAuthorizationFlow`-Objekt, wobei ` parent ` als übergeordnetes Objekt verwendet wird, und legt ` manager ` als Netzwerkzugriffsmanager fest.

[override virtual noexcept] QOAuth2DeviceAuthorizationFlow::~QOAuth2DeviceAuthorizationFlow()

Löscht die Instanz „ QOAuth2DeviceAuthorizationFlow “.

[signal] void QOAuth2DeviceAuthorizationFlow::authorizeWithUserCode(const QUrl &verificationUrl, const QString &userCode, const QUrl &completeVerificationUrl)

Dieses Signal wird ausgegeben, wenn der Benutzer die Autorisierung abschließen soll.

Wenn der Autorisierungsserver completeVerificationUrl bereitgestellt hat, kann der Benutzer zu dieser URL navigieren. Die URL enthält den erforderlichen userCode sowie alle weiteren erforderlichen Parameter.

Alternativ muss der Benutzer zu verificationUrl navigieren und userCode manuell eingeben.

Siehe auch Device Flow Usage.

[override virtual slot] void QOAuth2DeviceAuthorizationFlow::grant()

Implementiert neu: QAbstractOAuth::grant().

Startet den Autorisierungsablauf, wie im Device Grant RFC beschrieben.

Der Ablauf besteht aus folgenden Schritten:

  • Autorisierungsanfrage an den Autorisierungsserver
  • Der Benutzer autorisiert den Zugriff, siehe authorizeWithUserCode()
  • Abfrage des Autorisierungsservers, bis der Benutzer die Autorisierung akzeptiert oder abgelehnt hat (oder die Codes ablaufen)
  • Meldung des Ergebnisses an die Anwendung (siehe granted() und QAbstractOAuth::requestFailed())

Der Ablauf verläuft automatisch von der Autorisierung zur Abfrage des Tokens.

Durch den Aufruf dieser Funktion werden alle bisherigen Autorisierungsdaten zurückgesetzt.

Siehe auch authorizeWithUserCode(), granted(), QAbstractOAuth::requestFailed(), polling, startTokenPolling(), stopTokenPolling() und Device Flow Usage.

[protected slot, since 6.9] void QOAuth2DeviceAuthorizationFlow::refreshTokensImplementation()

Diese Funktion sendet eine Anfrage zur Aktualisierung des Tokens.

Wurde die Auffrischungsanforderung erfolgreich initiiert, wird der Status auf „ QAbstractOAuth::Status::RefreshingToken “ gesetzt; andernfalls wird das Signal „ requestFailed()“ ausgegeben und der Status bleibt unverändert. Token können nicht aktualisiert werden, solange „ isPolling “ den Status „ true “ hat.

Diese Funktion hat keine Auswirkung, wenn der Token-Aktualisierungsprozess bereits läuft.

Wenn die Aktualisierung des Tokens fehlschlägt und ein Zugriffstoken vorhanden ist, wird der Status auf „ QAbstractOAuth::Status::Granted “ gesetzt; wenn kein Zugriffstoken vorhanden ist, wird er auf „ QAbstractOAuth::Status::NotAuthenticated “ gesetzt.

Diese Funktion wurde in Qt 6.9 eingeführt.

Siehe auch QAbstractOAuth::requestFailed() und QAbstractOAuth2::refreshTokens().

[slot] bool QOAuth2DeviceAuthorizationFlow::startTokenPolling()

Startet die Token-Abfrage. Gibt „ true “ zurück, wenn der Start erfolgreich war (oder bereits aktiv war), andernfalls „ false “.

Der Aufruf dieser Funktion ist in einem typischen Anwendungsfall nicht erforderlich. Sobald die Autorisierungsanfrage abgeschlossen ist – als Ergebnis des Aufrufs von ` grant()` – wird die Abfrage automatisch gestartet.

Diese Funktion kann nützlich sein, wenn die Token-Abfrage etwas später fortgesetzt (erneut versucht) werden muss, ohne den gesamten Autorisierungsablauf neu zu starten. Zum Beispiel im Falle eines vorübergehenden Verlusts der Netzwerkverbindung.

Das Abfrageintervall wird vom Autorisierungsserver festgelegt und beträgt in der Regel 5 Sekunden. Die erste Abfrageanforderung wird gesendet, sobald das erste Intervall abgelaufen ist.

Siehe auch polling, stopTokenPolling() und Device Flow Usage.

[slot] void QOAuth2DeviceAuthorizationFlow::stopTokenPolling()

Beendet die Token-Abfrage. Etwaige noch ausstehende Abfrageanfragen werden ohne Rückmeldung verworfen.

Siehe auch polling und startTokenPolling().

© 2026 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.