Vue d'ensemble d'OAuth 2.0

RFC 6749 - Le cadre d'autorisation OAuth 2.0 spécifie un protocole pour l'autorisation de services en utilisant une application tierce. OAuth 2.0 utilise des jetons pour abstraire l'autorisation du service et des utilisateurs. Cette méthode est plus sûre car le propriétaire du service n'a pas besoin de gérer les informations d'identification de l'utilisateur. Elle remplace la RFC 5849 OAuth 1.0.

Le cadre OAuth 2.0 définit deux types de clients, public ou confidentiel, et des flux tels que le flux de code d'autorisation, l'octroi de code implicite et plusieurs autres pour l'autorisation. Une application Qt typique est considérée comme une application native publique. Une application client publique est une application à laquelle on ne peut pas faire confiance pour détenir des informations sensibles, telles que des mots de passe, à intégrer dans le binaire livré.

LaRFC 8252 OAuth 2.0 for Native Apps (OAuth 2.0 pour les applications natives) définit plus précisément les meilleures pratiques pour les applications natives. En particulier, la RFC 8252 recommande que le flux d'autorisation soit géré par le navigateur. Par conséquent, les classes QtNetworkAuth fournissent une implémentation concrète de ce flux.

Nouveau dans Qt 6.9, QtNetworkAuth fournit un support pour la RFC 8628 - OAuth 2.0 Device Authorization Grant. Ce flux est destiné aux appareils dont les capacités d'entrée sont limitées ou peu pratiques. Pour ce flux, les autorisations accordées utilisent un dispositif secondaire tel qu'un smartphone au lieu du dispositif lui-même. Des exemples de ces dispositifs sont les téléviseurs, les consoles multimédia, les IHM des machines et les dispositifs IoT. L'utilisateur peut ensuite utiliser une application sur son smartphone pour autoriser le dispositif.

Le tableau suivant présente les deux flux OAuth 2.0 pris en charge par Qt Network Authorization :

OAuth 2.0 nécessite l'utilisation d'un user-agent qui est généralement un navigateur. Pour plus d'informations, reportez-vous à Qt OAuth2 Browser Support.

Classes OAuth 2.0

Qt Network Authorization fournit des classes OAuth 2.0 concrètes et abstraites. Les classes abstraites sont destinées à la mise en œuvre de flux personnalisés, tandis que les classes concrètes fournissent une implémentation concrète.

Pour obtenir la liste des classes C++, consultez la page QtNetworkAuth.

Qt Network Authorization dispose de deux classes abstraites pour la mise en œuvre des flux OAuth 2.0 :

• Une classe d'implémentation de flux OAuth 2.0 fournit l'API principale et est l'orchestrateur du flux. La classe abstraite est QAbstractOAuth2, et les implémentations concrètes sont QOAuth2AuthorizationCodeFlow et QOAuth2DeviceAuthorizationFlow.
• Une classe de gestion des réponses qui gère les redirections et les réponses d'un serveur d'autorisation. La classe abstraite du gestionnaire de réponse est QAbstractOAuthReplyHandler, et les classes concrètes sont QOAuthHttpServerReplyHandler et QOAuthUriSchemeReplyHandler. La principale différence entre les gestionnaires de réponses est le type de redirections qu'ils gèrent. QOAuth2AuthorizationCodeFlow utilise un gestionnaire de réponses pour gérer les redirections et QOAuth2DeviceAuthorizationFlow, qui n'est pas basé sur les redirections, n'utilise pas de gestionnaires de réponses.

Flux du code d'autorisation

Cette section est une vue d'ensemble du flux de code d'autorisation du RFC 6749 - Code d'autorisation et du RFC 8252 - Demande d'autorisation à partir d'une application native pour les applications natives.

Considérons l'exemple de configuration suivant :

QOAuth2AuthorizationCodeFlow m_oauth;
QOAuthUriSchemeReplyHandler m_handler;

m_oauth.setAuthorizationUrl(QUrl(authorizationUrl));
m_oauth.setTokenUrl(QUrl(accessTokenUrl));
m_oauth.setClientIdentifier(clientIdentifier);
m_oauth.setRequestedScopeTokens({scope});

connect(&m_oauth, &QAbstractOAuth::authorizeWithBrowser, this, &QDesktopServices::openUrl);
connect(&m_oauth, &QAbstractOAuth::granted, this, [this]() {
    // Here we use QNetworkRequestFactory to store the access token
    m_api.setBearerToken(m_oauth.token().toLatin1());
    m_handler.close();
});

m_handler.setRedirectUrl(QUrl{"com.example.myqtapp://oauth2redirect"_L1});
m_oauth.setReplyHandler(&m_handler);

// Initiate the authorization
if (m_handler.listen()) {
    m_oauth.grant();
}

Étapes du flux d'autorisation

Le flux de code d'autorisation RFC 6749 comporte deux étapes principales : l'autorisation de la ressource (y compris l'authentification nécessaire de l'utilisateur) suivie d'une demande de jeton d'accès. Ces étapes sont éventuellement suivies de l'utilisation du jeton d'accès et du rafraîchissement du jeton d'accès. La figure suivante illustre ces étapes :

• Lors de la phase d'autorisation, l'utilisateur est authentifié et autorise l'accès aux ressources. Cela nécessite une interaction avec le navigateur de la part de l'utilisateur.
• Après l'autorisation, le code d'autorisation reçu est utilisé pour demander un jeton d'accès et, éventuellement, un jeton de rafraîchissement.
• Une fois le jeton d'accès obtenu, l'application l'utilise pour accéder aux ressources qui l'intéressent. Le jeton d'accès est inclus dans les demandes de ressources, et il appartient au serveur de ressources de vérifier la validité du jeton. Il existe plusieurs façons d'inclure le jeton dans les requêtes avec les jetons de support. L'inclusion du jeton dans l'en-tête HTTP Authorization est sans doute la plus courante.
• Actualisation du jeton d'accès. Les jetons d'accès expirent généralement assez rapidement, par exemple au bout d'une heure. Si l'application a reçu un jeton de rafraîchissement en plus du jeton d'accès, le jeton de rafraîchissement peut être utilisé pour demander un nouveau jeton d'accès. Les applications peuvent conserver des jetons de rafraîchissement de plus longue durée afin d'éviter une nouvelle étape d'autorisation (et donc une nouvelle interaction avec le navigateur).

Détails et personnalisation

Les flux OAuth 2.0 sont dynamiques et la mise en œuvre des spécifications peut s'avérer délicate au début. La figure ci-dessous illustre les principaux détails d'un flux de code d'autorisation réussi.

Par souci de clarté, la figure omet certains signaux, mais elle illustre les détails et les principaux points de personnalisation. Les points de personnalisation sont les divers signaux et emplacements que l'application peut utiliser, ainsi que les rappels qui sont réglés avec QAbstractOAuth::setModifyParametersFunction() et QAbstractOAuth2::setNetworkRequestModifier().

Choix d'un gestionnaire de réponse

Le choix du gestionnaire à utiliser dépend de l'élément redirect_uri. L'élément redirect_uri est défini à l'endroit où le navigateur est redirigé à la fin de l'étape d'autorisation.

Pour la réception de la réponse d'autorisation dans les applications natives, la RFC 8252 spécifie trois types principaux de schémas d'URI de réponse: private-use, loopback et https.

• URI à usage privé: Ils peuvent être utilisés si le système d'exploitation permet à une application d'enregistrer un schéma d'URI personnalisé. Une tentative d'ouverture d'une URL avec un tel schéma personnalisé ouvrira l'application native correspondante. Voir QOAuthUriSchemeReplyHandler.
• URI HTTPS: Peut être utilisé si le système d'exploitation permet à l'application d'enregistrer une URL HTTPS personnalisée. Toute tentative d'ouverture de cette URL entraînera l'ouverture de l'application native correspondante. Ce schéma est recommandé si le système d'exploitation le prend en charge. Voir QOAuthUriSchemeReplyHandler.
• Interfaces de bouclage: Elles sont couramment utilisées pour les applications de bureau et les applications en cours de développement. Le site QOAuthHttpServerReplyHandler est conçu pour gérer ces URI en mettant en place un serveur local pour gérer la redirection.

Le choix dépend de plusieurs facteurs tels que

• les URI de redirection pris en charge par le fournisseur du serveur d'autorisation. La prise en charge varie d'un fournisseur à l'autre et est souvent spécifique à un type de client et à un système d'exploitation particuliers. En outre, la prise en charge peut varier selon que l'application est publiée ou non.
• Schémas d'URI de redirection pris en charge par la (les) plate-forme(s) cible(s).
• Les exigences spécifiques à l'application en matière de convivialité, de sécurité et autres.

LeRFC 8252 recommande l'utilisation du schéma https pour ses avantages en termes de sécurité et de convivialité par rapport aux autres méthodes.

Octroi de l'autorisation OAuth 2.0 pour les appareils

LaRFC 8628 OAuth 2.0 Device Authorization Grant est destinée aux dispositifs connectés qui sont limités en termes de capacités d'entrée, ou lorsque l'utilisation de l'agent utilisateur-navigateur n'est pas pratique. Les appareils intelligents qui ont besoin de dispositifs externes pour l'autorisation sont des exemples d'appareils qui utilisent ce flux.

Considérons l'exemple de configuration suivant :

m_deviceFlow.setAuthorizationUrl(QUrl(authorizationUrl)) ; m_deviceFlow.setTokenUrl(QUrl(accessTokenUrl)) ; m_deviceFlow.setRequestedScopeTokens({scope}) ; m_deviceFlow.setClientIdentifier(clientIdentifier) ;// La nécessité d'un secret client dépend du serveur d'autorisationm_deviceFlow.setClientIdentifierSharedKey(clientSecret) ; connect(&m_deviceFlow, &QOAuth2DeviceAuthorizationFlow::authorizeWithUserCode, this,[](const QUrl &verificationUrl, const QString &userCode, const QUrl &completeVerificationUrl) { if (completeVerificationUrl.isValid()) { // Si le serveur d'autorisation a fourni une URL complète // qui contient déjà les données nécessaires dans les paramètres de l'URL, // vous pouvez choisir d'utiliser cetteURL .            qDebug() << "Complete verification uri:" << completeVerificationUrl;
        } else { // Le serveur d'autorisation n'a fourni que l'URL de vérification ; utilisez-la.            qDebug() << "Verification uri and usercode:" << verificationUrl << userCode;
        } } ) ; connect(&m_deviceFlow, &QAbstractOAuth::granted, this, [this](){ // Nous utilisons ici QNetworkRequestFactory pour stocker le jeton d'accèsm_api.setBearerToken(m_deviceFlow.token().toLatin1()) ; }) ; m_deviceFlow.grant() ;

Étapes de l'octroi de l'autorisation de l'appareil

Le flux d'octroi d'autorisation d'appareil comporte trois étapes principales : l'initialisation de l'autorisation, l'interrogation des jetons et l'achèvement de l'autorisation. Ces étapes sont éventuellement suivies de l'utilisation et du rafraîchissement des jetons. La figure suivante illustre ces étapes :

• L'autorisation est initialisée par l'envoi d'une requête HTTP au serveur d'autorisation. Le serveur d'autorisation fournit en réponse un code d'utilisateur, des URL de vérification et un code d'appareil.
• Après l'initialisation de l'autorisation, l'utilisateur reçoit un code d'utilisateur et des URL de vérification pour compléter l'autorisation. Le mécanisme pour l'utilisateur final varie : il peut s'agir d'un URL visible sur l'écran, d'un code QR, d'un courriel, etc. Pour plus d'informations, voir RFC 8628 - User Interaction.
• En attendant que l'utilisateur final termine l'autorisation, le flux du dispositif interroge le serveur d'autorisation pour obtenir des jetons. Le code du dispositif reçu à l'étape précédente est utilisé pour faire correspondre la session d'autorisation. L'intervalle d'interrogation est déterminé par le serveur d'autorisation et est généralement de 5 secondes.
• Une fois que l'utilisateur final a accepté ou refusé l'autorisation, le serveur d'autorisation répond à une demande d'interrogation avec les jetons demandés ou un code d'erreur en cas de refus, et l'autorisation est terminée.

Détails et personnalisation

La figure suivante illustre plus en détail le flux d'octroi de l'autorisation de l'appareil. Elle montre les principaux points de personnalisation, qui sont parfois nécessaires. Par exemple, des paramètres propriétaires ou des informations d'authentification supplémentaires.

Jetons de rafraîchissement

Les jetons de rafraîchissement exigent que le serveur d'autorisation fournisse un jeton de rafraîchissement pendant l'autorisation. La fourniture d'un jeton de rafraîchissement est laissée à l'appréciation du serveur d'autorisation : certains serveurs peuvent choisir de toujours le fournir, d'autres ne le fournissent jamais et d'autres encore le fournissent si une adresse scope spécifique était présente dans la demande d'autorisation.

La figure suivante illustre le rafraîchissement du jeton de manière plus détaillée :

Comme le montre la figure ci-dessus, les points de personnalisation habituels sont également disponibles lors du rafraîchissement des jetons.

Pour rafraîchir les jetons après le démarrage d'une application, celle-ci doit conserver le jeton de rafraîchissement en toute sécurité et le définir à l'aide de QAbstractOAuth2::setRefreshToken. QAbstractOAuth2::refreshTokens peut ensuite être appelé pour demander de nouveaux jetons.

Nouveauté de Qt 6.9, les applications peuvent rafraîchir automatiquement les jetons - voir QAbstractOAuth2::accessTokenAboutToExpire, QAbstractOAuth2::autoRefresh, et QAbstractOAuth2::refreshLeadTime.

Le délai d'expiration d'un jeton de rafraîchissement n'est généralement pas indiqué par le serveur d'autorisation (à l'exception de la documentation du serveur). Leur validité peut aller de quelques jours à plusieurs mois, voire plus. En outre, comme les autres jetons, les jetons de rafraîchissement peuvent être révoqués par l'utilisateur et donc invalidés à tout moment. Il est donc important de détecter correctement l'échec d'une tentative de rafraîchissement à l'aide de QAbstractOAuth::requestFailed ou QAbstractOAuth2::serverReportedErrorOccurred.

Les flux OAuth 2.0 nécessitent de nombreuses interactions avec l'utilisateur, ce qui peut nuire à son expérience. Pour minimiser ces interactions, les tokens peuvent être rafraîchis silencieusement pour l'utilisateur. Pour plus d'informations, consultez la RFC 6749 - Refreshing Access Tokens (rafraîchissement des jetons d'accès).

Prise en charge de Qt OpenID Connect

OpenID Connect (OIDC) est une simple couche d'identité au-dessus d'OAuth 2.0. OIDC peut utiliser un serveur d'autorisation pour authentifier l'identité d'un utilisateur. L'accès à des informations simples sur le profil de l'utilisateur est également possible avec OIDC.

Le support de Qt pour OIDC est pour l'instant limité à l'obtention de jetons d'identification. Un jeton d'identification est un jeton Web JSON (JWT ) qui contient des informations sur l'événement d'authentification.

En supposant que l'application soit capable de valider les jetons reçus, le jeton peut être utilisé pour établir l'identité de l'utilisateur de manière fiable (tant que le fournisseur OIDC lui-même est digne de confiance).

Les jetons d'identification sont des informations sensibles qui doivent être gardées secrètes et ne sont pas identiques aux jetons d'accès. Les jetons d'identification ne sont pas destinés à être envoyés lors d'appels à l'API - le jeton d'accès est prévu à cet effet. Notez que certains fournisseurs peuvent utiliser le même format JWT pour les jetons d'accès, mais il ne faut pas le confondre avec les jetons d'identification proprement dits, qui utilisent le même format. Avec les jetons d'identification, le client qui reçoit le jeton est responsable de sa vérification, alors qu'avec les jetons d'accès, c'est le serveur de ressources qui accepte le jeton qui est responsable de la vérification.

Obtenir un jeton d'identification

L'obtention d'un jeton d'identification est similaire à celle d'un jeton d'accès. Tout d'abord, nous devons définir le champ d'application approprié. Le fournisseur du serveur d'autorisation peut prendre en charge des spécificateurs d'étendue supplémentaires tels que profile et email, mais toutes les demandes OIDC doivent inclure l'étendue openid:

m_oauth.setRequestedScopeTokens({"openid"});

Pour l'OIDC, il est fortement recommandé d'utiliser le paramètre nonce. Pour ce faire, il convient de s'assurer que le paramètre NonceMode est défini de manière appropriée.

// This is for illustrative purposes, 'Automatic' is the default mode
m_oauth.setNonceMode(QAbstractOAuth2::NonceMode::Automatic);

La dernière étape consiste à écouter soit le signal QAbstractOAuth2::granted, soit directement le signal QAbstractOAuth2::idTokenChanged:

connect(&m_oauth, &QAbstractOAuth2::idTokenChanged, this, [this](const QString &token) {
    Q_UNUSED(token); // Handle token
});

Validation d'un jeton d'identification

La validation du jeton d'identification reçu est une partie essentielle du flux d'authentification et, lorsqu'elle est pleinement mise en œuvre, une tâche quelque peu compliquée. Reportez-vous à l'intégralité du document OpenID Connect ID Validation.

Pour résumer, la validation consiste en ces étapes :

• Décryptage du jeton si nécessaire(voir JWE)
• Extraction de l'en-tête, de la charge utile et de la signature du jeton
• Validation de la signature
• Validation des champs de la charge utile (tels que aud, iss, exp, nonce, iat)

Qt ne fournit actuellement pas de support pour la validation des jetons d'identification, mais il existe des bibliothèques JWT tierces, telles que jwt-cpp.

Exemple de vérification de jeton d'identification

Cette section présente un exemple simple de vérification. Comme conditions préalables, l'environnement de développement doit disposer des bibliothèques OpenSSL et jwt-cpp dans le dossier include du répertoire source du projet d'application.

Dans le fichier CMakeLists.txt du projet d'application, nous vérifions d'abord que les conditions préalables sont remplies :

find_package(OpenSSL 1.0.0 QUIET)
set(JWT_CPP_INCLUDE_DIR "${CMAKE_SOURCE_DIR}/include")
if(OPENSSL_FOUND AND EXISTS "${JWT_CPP_INCLUDE_DIR}/jwt-cpp/jwt.h")

Ensuite, nous ajoutons les inclusions et les bibliothèques nécessaires :

    target_include_directories(networkauth_oauth_snippets PRIVATE "${JWT_CPP_INCLUDE_DIR}")
    target_link_libraries(networkauth_oauth_snippets PRIVATE OpenSSL::SSL OpenSSL::Crypto)
    target_compile_definitions(networkauth_oauth_snippets PRIVATE JWT_CPP_AVAILABLE)

Dans les fichiers source de l'application, inclure la bibliothèque de vérification :

#ifdef JWT_CPP_AVAILABLE
#include "jwt-cpp/jwt.h"
#endif

Une fois que l'application a reçu un jeton d'identification, il est temps de le vérifier. Tout d'abord, nous trouvons une clé correspondante à partir de JSON Web Key Sets (JWKS), voir OpenID Connect Discovery).

try {
    const auto jwt = jwt::decode(m_oauth.idToken().toStdString());
    const auto jwks = jwt::parse_jwks(m_jwks->toJson(QJsonDocument::Compact).toStdString());
    const auto jwk = jwks.get_jwk(jwt.get_key_id());

Ensuite, nous procédons à la vérification proprement dite :

   // Nous utilisons ici le module et l'exposant pour dériver la clé const auto n = jwk.get_jwk_claim("n").as_string() ; // module const auto e = jwk.get_jwk_claim("e").as_string() ; // exposant if (n.empty() || e.empty()) {        qWarning() << "Modulus or exponent empty";
       return false; } if (jwt.get_algorithm() != "RS256") { // Cet exemple ne supporte que RS256        qWarning() << "Unsupported algorithm:" << jwt.get_algorithm();
       return false; } if (jwk.get_jwk_claim("kty").as_string() != "RSA") {        qWarning() << "Unsupported key type:" << jwk.get_jwk_claim("kty").as_string();
       return false; } if (jwk.has_jwk_claim("use") && jwk.get_jwk_claim("use").as_string() != "sig") {        qWarning() << "Key not for signature" << jwk.get_jwk_claim("use").as_string();
       return false; } // Vérification  minimale simple (omet les cas spéciaux et par exemple la vérification 'sub'). // jwt-cpp vérifie aussi 'exp', 'iat', et 'nbf' s'ils sont présents. const auto keyPEM = jwt::helper::create_public_key_from_rsa_components(n, e) ; auto verifier = jwt::verify() .allow_algorithm(jwt::algorithm::rs256(keyPEM)) . with_claim("nonce", jwt::claim(m_oauth.nonce().toStdString())) . with_issuer(m_oidcConfig->value("issuer"_L1).toString().toStdString()) . with_audience(std::string(clientIdentifier.data()) . leeway(60UL) ; verifier.verify(jwt) ;    qDebug() << "ID Token verified successfully";
   return true; } catch(const std::exception &e) { // Gérer l'erreur. Alternativement, passer le paramètre d'erreur aux appels jwt-cpp    qWarning() << "ID Token verification failed" << e.what();
   return false; }

Lecture des valeurs des jetons d'identification

Le jeton d'identification est au format JSON Web Token (JWT ) et se compose d'un en-tête, d'une charge utile et d'une signature, séparés par des points ..

La lecture des valeurs du jeton d'identification est simple. À titre d'exemple, supposons qu'il existe une struct :

struct IDToken {
    QJsonObject header;
    QJsonObject payload;
    QByteArray signature;
};

et une fonction :

std::optional<IDToken> parseIDToken(const QString &token) const;

Le jeton peut être extrait avec :

if (token.isEmpty())
    return std::nullopt;

QList<QByteArray> parts = token.toLatin1().split('.');
if (parts.size() != 3)
    return std::nullopt;

QJsonParseError parsing;

QJsonDocument header = QJsonDocument::fromJson(
    QByteArray::fromBase64(parts.at(0), QByteArray::Base64UrlEncoding), &parsing);
if (parsing.error != QJsonParseError::NoError || !header.isObject())
    return std::nullopt;

QJsonDocument payload = QJsonDocument::fromJson(
    QByteArray::fromBase64(parts.at(1), QByteArray::Base64UrlEncoding), &parsing);
if (parsing.error != QJsonParseError::NoError || !payload.isObject())
    return std::nullopt;

QByteArray signature = QByteArray::fromBase64(parts.at(2), QByteArray::Base64UrlEncoding);

return IDToken{header.object(), payload.object(), signature};

Dans certains cas, le jeton peut être crypté en tant que JSON Web Encryption (JWE ) qui contient en interne un jeton JWT. Dans ce cas, le jeton doit d'abord être décrypté.

Découverte d'OpenID Connect

OpenID Connect Discovery définit les moyens de découvrir les détails du fournisseur OpenID nécessaire pour interagir avec lui. Il s'agit notamment d'informations telles que les URL authorization_endpoint et token_endpoint.

Bien que ces informations sur les fournisseurs puissent être configurées de manière statique dans l'application, la découverte de ces informations au moment de l'exécution peut offrir plus de souplesse et de robustesse dans l'interaction avec les différents fournisseurs.

L'obtention du document de découverte est une simple requête HTTP GET. Le document se trouve généralement à l'adresse https://<domain name>/.well-known/openid_configuration.

m_network->get(request, this, [this](QRestReply &reply) {
    if (reply.isSuccess()) {
        if (auto doc = reply.readJson(); doc && doc->isObject())
            m_oidcConfig = doc->object(); // Store the configuration
    }
});

Notamment, pour la validation des jetons, le champ jwks_uri fournit un lien permettant d'accéder aux informations d'identification de sécurité (publiques) actuelles. Il n'est donc plus nécessaire de coder en dur ces informations d'identification dans l'application. Cela facilite également la rotation des clés ; les fournisseurs peuvent modifier les clés utilisées de temps à autre, et il est donc important de disposer d'une clé à jour.

Pour obtenir les clés, il suffit d'une simple requête HTTP GET :

m_network->get(request, this, [this](QRestReply &reply) {
    if (reply.isSuccess()) {
        if (auto doc = reply.readJson(); doc && doc->isObject())
            m_jwks = doc; // Use the keys later to verify tokens
    }
});

Le jeu de clés contient généralement plusieurs clés. La clé correcte est indiquée dans l'en-tête JWT (il faut veiller à ce que les clés correspondent correctement, une simple vérification du champ d'identification de la clé, kid, n'est pas suffisante).

Point final OpenID UserInfo

Une autre façon d'accéder aux informations sur l'utilisateur est d'utiliser le point de terminaison UserInfo d'OpenID Connect, si le fournisseur OIDC le prend en charge. L'URL du userinfo se trouve dans le champ userinfo_endpoint du document OpenID Connect Discovery.

Le point de terminaison UserInfo n'utilise pas le jeton d'identification, mais on y accède avec le jeton d'accès. L'accès à UserInfo est similaire à l'accès à toute autre ressource avec un jeton d'accès.

En supposant que le jeton d'accès soit reçu et défini par exemple par :

QNetworkRequestFactory userInfoApi(url);
userInfoApi.setBearerToken(m_oauth.token().toLatin1());

L'accès aux UserInfo se fait alors par une requête HTTP GET :

m_network->get(userInfoApi.createRequest(), this, [this](QRestReply &reply) { if (reply.isSuccess()) { if(auto doc = reply.readJson() ; doc &&  doc->isObject())            qDebug() << doc->object(); // Use the userinfo
    } }) ;