Script 'mail_helper' called by obssrc
Hello community,
here is the log from the commit of package qt6-networkauth for openSUSE:Factory
checked in at 2025-10-13 17:23:40
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/qt6-networkauth (Old)
and /work/SRC/openSUSE:Factory/.qt6-networkauth.new.18484 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "qt6-networkauth"
Mon Oct 13 17:23:40 2025 rev:38 rq:1310353 version:6.10.0
Changes:
--------
--- /work/SRC/openSUSE:Factory/qt6-networkauth/qt6-networkauth.changes
2025-08-29 18:35:43.779409525 +0200
+++
/work/SRC/openSUSE:Factory/.qt6-networkauth.new.18484/qt6-networkauth.changes
2025-10-13 17:26:33.477342661 +0200
@@ -1,0 +2,6 @@
+Tue Oct 7 08:53:25 UTC 2025 - Christophe Marin <[email protected]>
+
+- Update to 6.10.0
+ * https://www.qt.io/blog/qt-6.10-released
+
+-------------------------------------------------------------------
Old:
----
qtnetworkauth-everywhere-src-6.9.2.tar.xz
New:
----
qtnetworkauth-everywhere-src-6.10.0.tar.xz
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ qt6-networkauth.spec ++++++
--- /var/tmp/diff_new_pack.t80Xh2/_old 2025-10-13 17:26:35.509427635 +0200
+++ /var/tmp/diff_new_pack.t80Xh2/_new 2025-10-13 17:26:35.509427635 +0200
@@ -16,8 +16,8 @@
#
-%define real_version 6.9.2
-%define short_version 6.9
+%define real_version 6.10.0
+%define short_version 6.10
%define short_name qtnetworkauth
%define tar_name qtnetworkauth-everywhere-src
%define tar_suffix %{nil}
@@ -28,7 +28,7 @@
%endif
#
Name: qt6-networkauth%{?pkg_suffix}
-Version: 6.9.2
+Version: 6.10.0
Release: 0
Summary: Set of APIs to obtain limited access to online accounts and
HTTP services
License: GPL-3.0-only WITH Qt-GPL-exception-1.0
@@ -105,7 +105,7 @@
%{_qt6_includedir}/QtNetworkAuth/
%{_qt6_libdir}/libQt6NetworkAuth.prl
%{_qt6_libdir}/libQt6NetworkAuth.so
-%{_qt6_metatypesdir}/qt6networkauth_*_metatypes.json
+%{_qt6_metatypesdir}/qt6networkauth_metatypes.json
%{_qt6_mkspecsdir}/modules/qt_lib_networkauth.pri
%{_qt6_pkgconfigdir}/Qt6NetworkAuth.pc
%exclude %{_qt6_includedir}/QtNetworkAuth/%{real_version}
++++++ qtnetworkauth-everywhere-src-6.9.2.tar.xz ->
qtnetworkauth-everywhere-src-6.10.0.tar.xz ++++++
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/qtnetworkauth-everywhere-src-6.9.2/.cmake.conf
new/qtnetworkauth-everywhere-src-6.10.0/.cmake.conf
--- old/qtnetworkauth-everywhere-src-6.9.2/.cmake.conf 2025-08-17
21:32:14.000000000 +0200
+++ new/qtnetworkauth-everywhere-src-6.10.0/.cmake.conf 2025-10-01
20:34:32.000000000 +0200
@@ -1,4 +1,4 @@
-set(QT_REPO_MODULE_VERSION "6.9.2")
+set(QT_REPO_MODULE_VERSION "6.10.0")
set(QT_REPO_MODULE_PRERELEASE_VERSION_SEGMENT "alpha1")
set(QT_EXTRA_INTERNAL_TARGET_DEFINES "QT_NO_AS_CONST=1")
list(APPEND QT_EXTRA_INTERNAL_TARGET_DEFINES "QT_NO_FOREACH=1")
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/qtnetworkauth-everywhere-src-6.9.2/.tag
new/qtnetworkauth-everywhere-src-6.10.0/.tag
--- old/qtnetworkauth-everywhere-src-6.9.2/.tag 2025-08-17 21:32:14.000000000
+0200
+++ new/qtnetworkauth-everywhere-src-6.10.0/.tag 2025-10-01
20:34:32.000000000 +0200
@@ -1 +1 @@
-ed02dfd0363a5739aeb1ff341b946aaed56fb6fb
+ff34e1ae68601b3437a7fd6eef412894b08dd0c0
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/qtnetworkauth-everywhere-src-6.9.2/dependencies.yaml
new/qtnetworkauth-everywhere-src-6.10.0/dependencies.yaml
--- old/qtnetworkauth-everywhere-src-6.9.2/dependencies.yaml 2025-08-17
21:32:14.000000000 +0200
+++ new/qtnetworkauth-everywhere-src-6.10.0/dependencies.yaml 2025-10-01
20:34:32.000000000 +0200
@@ -1,4 +1,4 @@
dependencies:
../qtbase:
- ref: 6f0d27d2e4ba5fa6562f738aaaf8eaf98ebf51e7
+ ref: 5a8637e4516bc48a0b3f4b5ec3b18618b92e7222
required: true
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/qtnetworkauth-everywhere-src-6.9.2/src/oauth/doc/qtnetworkauth.qdocconf
new/qtnetworkauth-everywhere-src-6.10.0/src/oauth/doc/qtnetworkauth.qdocconf
--- old/qtnetworkauth-everywhere-src-6.9.2/src/oauth/doc/qtnetworkauth.qdocconf
2025-08-17 21:32:14.000000000 +0200
+++
new/qtnetworkauth-everywhere-src-6.10.0/src/oauth/doc/qtnetworkauth.qdocconf
2025-10-01 20:34:32.000000000 +0200
@@ -16,7 +16,7 @@
qhp.QtNetworkAuth.subprojects = overview classes
qhp.QtNetworkAuth.subprojects.overview.title = Overview
-qhp.QtNetworkAuth.subprojects.overview.indexTitle = Qt OAuth2 Overview
+qhp.QtNetworkAuth.subprojects.overview.indexTitle = OAuth 2.0 Overview
qhp.QtNetworkAuth.subprojects.overview.selectors = group:none
qhp.QtNetworkAuth.subprojects.classes.title = C++ Classes
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/qtnetworkauth-everywhere-src-6.9.2/src/oauth/doc/src/external-resources.qdoc
new/qtnetworkauth-everywhere-src-6.10.0/src/oauth/doc/src/external-resources.qdoc
---
old/qtnetworkauth-everywhere-src-6.9.2/src/oauth/doc/src/external-resources.qdoc
1970-01-01 01:00:00.000000000 +0100
+++
new/qtnetworkauth-everywhere-src-6.10.0/src/oauth/doc/src/external-resources.qdoc
2025-10-01 20:34:32.000000000 +0200
@@ -0,0 +1,156 @@
+// Copyright (C) 2025 The Qt Company Ltd.
+// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR
GFDL-1.3-no-invariants-only
+
+/*!
+ \externalpage https://datatracker.ietf.org/doc/html/rfc7636
+ \title RFC 7636
+*/
+
+/*!
+ \externalpage https://datatracker.ietf.org/doc/html/rfc6749
+ \title RFC 6749
+*/
+
+/*!
+ \externalpage https://datatracker.ietf.org/doc/html/rfc6749#section-1.3.1
+ \title RFC 6749 - Authorization Code
+*/
+
+/*!
+ \externalpage https://datatracker.ietf.org/doc/html/rfc6749#appendix-A.6
+ \title RFC 6749 - redirect_uri Syntax
+*/
+
+/*!
+ \externalpage https://datatracker.ietf.org/doc/html/rfc6749#section-1.5
+ \title RFC 6749 - Refresh Token
+*/
+
+/*!
+ \externalpage https://datatracker.ietf.org/doc/html/rfc6749#section-6
+ \title RFC 6749 - Refreshing Access Tokens
+*/
+
+/*!
+ \externalpage https://datatracker.ietf.org/doc/html/rfc8252
+ \title RFC 8252
+*/
+
+/*!
+ \externalpage https://datatracker.ietf.org/doc/html/rfc8252#section-6
+ \title RFC 8252 - Authorization Request from a Native App
+*/
+
+/*!
+ \externalpage https://datatracker.ietf.org/doc/html/rfc8252#section-7
+ \title RFC 8252 - Authorization Response in a Native App
+*/
+
+/*!
+ \externalpage https://datatracker.ietf.org/doc/html/rfc8252#section-7.1
+ \title RFC 8252 - Private-Use URI Scheme Redirection
+*/
+
+/*!
+ \externalpage https://datatracker.ietf.org/doc/html/rfc8252#section-7.2
+ \title RFC 8252 - Claimed https Scheme URI Redirection
+*/
+
+/*!
+ \externalpage https://datatracker.ietf.org/doc/html/rfc8252#section-7.3
+ \title RFC 8252 - Loopback Interface Redirection
+*/
+
+/*!
+ \externalpage https://datatracker.ietf.org/doc/html/rfc5849
+ \title RFC 5849
+*/
+
+/*!
+ \externalpage https://datatracker.ietf.org/doc/html/rfc8628
+ \title RFC 8628
+*/
+
+/*!
+ \externalpage https://datatracker.ietf.org/doc/html/rfc8628#section-3.3
+ \title RFC 8628 - User Interaction
+*/
+
+/*!
+ \externalpage https://oauth.net
+ \title OAuth
+*/
+
+/*!
+ \externalpage https://oauth.net/1/
+ \title OAuth 1
+*/
+/*!
+ \externalpage https://oauth.net/2/
+ \title OAuth 2.0
+*/
+
+/*!
+ \externalpage http://openid.net/
+ \title OpenID
+*/
+
+/*!
+ \externalpage http://openid.net/connect/
+ \title OpenID Connect
+*/
+
+/*!
+ \externalpage https://openid.net/specs/openid-connect-core-1_0-final.html
+ \title OpenID Connect Core
+*/
+
+/*!
+ \externalpage
https://openid.net/specs/openid-connect-core-1_0-final.html#IDTokenValidation
+ \title OpenID Connect ID Validation
+*/
+
+/*!
+ \externalpage https://openid.net/specs/openid-connect-discovery-1_0.html
+ \title OpenID Connect Discovery
+*/
+
+/*!
+ \externalpage
https://openid.net/specs/openid-connect-core-1_0-final.html#UserInfo
+ \title OpenID Connect UserInfo Endpoint
+*/
+
+/*!
+ \externalpage https://datatracker.ietf.org/doc/html/rfc6750
+ \title RFC 6750
+*/
+
+/*!
+ \externalpage https://datatracker.ietf.org/doc/html/rfc6750#section-2.1
+ \title RFC 6750 - Header Field
+*/
+
+/*!
+ \externalpage https://datatracker.ietf.org/doc/html/rfc7516
+ \title JSON Web Encryption (JWE)
+*/
+
+/*!
+ \externalpage https://datatracker.ietf.org/doc/html/rfc7517#section-5
+ \title JSON Web Key (JWK) Set Format
+*/
+
+/*!
+ \externalpage https://datatracker.ietf.org/doc/html/rfc7519
+ \title JSON Web Token (JWT)
+*/
+
+/*!
+ \externalpage https://jwt.io/libraries
+ \title Third-party JWT Libraries
+*/
+
+/*!
+ \externalpage https://github.com/Thalhammer/jwt-cpp
+ \title jwt-cpp
+*/
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/qtnetworkauth-everywhere-src-6.9.2/src/oauth/doc/src/qtnetworkauth-oauth2-browsersupport.qdoc
new/qtnetworkauth-everywhere-src-6.10.0/src/oauth/doc/src/qtnetworkauth-oauth2-browsersupport.qdoc
---
old/qtnetworkauth-everywhere-src-6.9.2/src/oauth/doc/src/qtnetworkauth-oauth2-browsersupport.qdoc
2025-08-17 21:32:14.000000000 +0200
+++
new/qtnetworkauth-everywhere-src-6.10.0/src/oauth/doc/src/qtnetworkauth-oauth2-browsersupport.qdoc
2025-10-01 20:34:32.000000000 +0200
@@ -10,7 +10,7 @@
\section1 OAuth2 User-Agents
-OAuth2 \l{Qt OAuth2 Overview}{Authorization stage}
+OAuth2 \l{OAuth 2.0 Overview}{Authorization stage}
\l{https://datatracker.ietf.org/doc/html/rfc6749#section-9}{relies on a
user-agent},
which is typically either the system browser or an embedded user-agent such as
\l {Qt WebEngine Overview}{Qt WebEngine}.
@@ -72,7 +72,7 @@
concluded.
For further details and supported redirect URL schemes with
-system browser please see \l{Qt OAuth2 Overview},
+system browser please see \l{OAuth 2.0 Overview},
\l {QOAuthHttpServerReplyHandler}, and \l {QOAuthUriSchemeReplyHandler}.
\section2 Using Qt WebEngine
@@ -92,7 +92,7 @@
\li QtQuick vs QtWidgets Applications. This impacts how to set up the
necessary integration with QtNetworkAuth classes.
\li Redirect URI scheme. This impacts which QtNetworkAuth reply handler
- classes to use, and how (see \l {Qt OAuth2 Overview}).
+ classes to use, and how (see \l {OAuth 2.0 Overview}).
\endlist
\section3 QtQuick and QtWidgets Applications
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/qtnetworkauth-everywhere-src-6.9.2/src/oauth/doc/src/qtnetworkauth-oauth2-overview.qdoc
new/qtnetworkauth-everywhere-src-6.10.0/src/oauth/doc/src/qtnetworkauth-oauth2-overview.qdoc
---
old/qtnetworkauth-everywhere-src-6.9.2/src/oauth/doc/src/qtnetworkauth-oauth2-overview.qdoc
2025-08-17 21:32:14.000000000 +0200
+++
new/qtnetworkauth-everywhere-src-6.10.0/src/oauth/doc/src/qtnetworkauth-oauth2-overview.qdoc
2025-10-01 20:34:32.000000000 +0200
@@ -4,39 +4,38 @@
/*!
\page qt-oauth2-overview.html
-\title Qt OAuth2 Overview
+\title OAuth 2.0 Overview
\ingroup explanations-networkauth
-\brief An overview of QtNetworkAuth OAuth2
+\brief Overview of OAuth 2.0 support in Qt
-\section1 OAuth2
+\l{RFC 6749}{RFC 6749 - The OAuth 2.0 Authorization Framework}
+specifies a protocol for authorization of services by using a third-party
+application. OAuth 2.0 uses tokens to abstract the authorization from the
+service and users. This method is safer as the service owner does not need to
+deal with user credentials. It is a replacement for \l{RFC 5849} OAuth 1.0.
+
+The OAuth 2.0 framework defines two \e{client types}, public or confidential,
+and \e flows such as the authorization code flow, implicit code grant, and
+several others for authorization. A typical Qt application is considered a
+\e{public native application}. A public client application is an application
+that can't trusted to hold sensitive information, such as passwords, to be
+embedded within the shipped binary.
+
+\l{RFC 8252}{RFC 8252 OAuth 2.0 for Native Apps} further defines the best
+practices for native applications. Specifically, RFC 8252 recommends the
+the authorization flow with the browser. Therefore, the
+\l QtNetworkAuth classes provide a concrete implementation of this flow.
+
+New in Qt 6.9, QtNetworkAuth provides support for \l{RFC 8628} -
+OAuth 2.0 Device Authorization Grant. This \e{device flow} is intended for
+devices that have limited or impractical input capabilities. For this flow,
+authorization grants use a secondary device such as smartphones instead of the
+device. Examples of these devices are televisions, media consoles, machine
HMIs,
+and IoT devices. The user may then use an application on their smartphone to
+authorize the device.
-\l {https://datatracker.ietf.org/doc/html/rfc6749}{RFC 6749 OAuth 2.0}
-defines an authorization framework which enables resource authorization
-without exposing sensitive user credentials such as passwords.
-
-The OAuth2 framework defines several client types (public and confidential)
-as well as flows (implicit, authorization code, and several others).
-For typical Qt applications the client type should be considered as
-\e {public native} application. The \e {public} implies that the
-application isn't trusted to hold secrets, such as passwords, embedded
-within the shipped binary.
-
-\l {https://datatracker.ietf.org/doc/html/rfc8252}{RFC 8252 OAuth 2.0 for
Native Apps}
-further defines the best practices for such applications. Among other things,
-it defines the
-\l {https://datatracker.ietf.org/doc/html/rfc8252#section-6}{Authorization
Code Flow}
-as the recommended flow, and therefore QtNetworkAuth provides a concrete
-implementation of this flow.
-
-Since Qt 6.9, QtNetworkAuth also provides support for
-\l {https://datatracker.ietf.org/doc/html/rfc8628}{RFC 8628 OAuth 2.0 Device
Authorization Grant}.
-This \e {device flow} is intended for connected devices that have limited input
-capabilities, or where using a user-agent or browser is not practical.
-Examples of such devices include televisions, media consoles, machine HMIs,
-and IoT devices.
-
-The following table highlights the main aspects of the two concrete OAuth2
-flows supported by QtNetworkAuth module:
+The following table highlights the two OAuth 2.0 flows supported by
+Qt Network Authorization:
\table
\header
@@ -65,41 +64,43 @@
\li TVs, Consoles, HMIs, IoT Devices
\endtable
-OAuth2 requires using a user-agent which is typically a browser.
-For further information, see \l {Qt OAuth2 Browser Support}.
+OAuth 2.0 requires using a user-agent which is typically a browser.
+For further information, refer to \l{Qt OAuth2 Browser Support}.
-\section1 Qt OAuth2 Classes
+\section1 OAuth 2.0 classes
-QtNetworkAuth provides both concrete and abstract OAuth2 classes.
+Qt Network Authorization provides both concrete and abstract OAuth 2.0 classes.
The abstract classes are intended for implementing custom flows, while
the concrete classes provide a concrete implementation.
-QtNetworkAuth has two abstract classes for implementing OAuth2 flows:
+For the list of C++ classes, refer to the \l QtNetworkAuth page.
+
+Qt Network Authorization has two abstract classes for implementing OAuth 2.0
+flows:
\list
- \li An \e {OAuth2 flow implementation} class provides the main API,
+ \li An \e {OAuth 2.0 flow implementation} class provides the main API,
and is the orchestrator of the flow. The abstract class is
QAbstractOAuth2, and the concrete implementations are
QOAuth2AuthorizationCodeFlow and QOAuth2DeviceAuthorizationFlow.
- \li A \e {Reply handler} class which handles redirects and replies
+ \li A \e {reply handler} class which handles redirects and replies
from an authorization server. The reply handler abstract class
is QAbstractOAuthReplyHandler, and the concrete classes are
QOAuthHttpServerReplyHandler and QOAuthUriSchemeReplyHandler.
- The main difference between reply handlers is what kind
- of redirects they are designed to handle. QOAuth2AuthorizationCodeFlow
- relies on having a reply handler to handle the redirects,
- whereas QOAuth2DeviceAuthorizationFlow, which is not based on
+ The main difference between the reply handlers is the type
+ of redirects they handle. QOAuth2AuthorizationCodeFlow
+ uses a reply handler to handle the redirects and
+ QOAuth2DeviceAuthorizationFlow, which is not based on
redirects, does not use reply handlers.
\endlist
-\section1 Authorization Code Flow
+\section1 Authorization code flow
-The \l
{https://datatracker.ietf.org/doc/html/rfc6749#section-1.3.1}{authorization
code flow}
-is the
-\l {https://datatracker.ietf.org/doc/html/rfc8252#section-6}{recommended
OAuth2 flow}
-for native applications like Qt applications.
-
-The following code snippet provides an example setup:
+This section is an overview of the authorization code flow from
+\l{RFC 6749 - Authorization Code} and
+\l{RFC 8252 - Authorization Request from a Native App} for native
+applications.
+Consider the following sample setup:
\snippet src_oauth_replyhandlers_p.h uri-variables
\codeline
\snippet src_oauth_replyhandlers.cpp uri-service-configuration
@@ -108,14 +109,16 @@
\codeline
\snippet src_oauth_replyhandlers.cpp uri-handler-setup
-\section2 Stages
+\section2 Authorization flow stages
-The Authorization Code Flow has two main stages: resource authorization
-(including any necessary user authentication) followed up by an access
+The RFC 6749 Authorization Code Flow has two main stages: resource
authorization
+(including any necessary user authentication) followed by an access
token request. These are optionally followed by access token usage and
access token refreshing. The following figure illustrates these stages:
\image oauth2-codeflow-stages.webp
+{Simplified authorization process in a Qt application using an authorization
+server and a browser}
\list
\li In authorization stage, the user is authenticated, and
@@ -128,57 +131,57 @@
access the resources of interest. The access token is included
in the resource requests, and it is up to the resource server
to verify the token's validity.
- \l {https://datatracker.ietf.org/doc/html/rfc6750}{There are several
- ways to include the token as part of the requests}, but
- including it in the \l
{https://datatracker.ietf.org/doc/html/rfc6750#section-2.1}
- {HTTP \c Authorization header} is arguably the most common.
+ There are several ways to include the token as part of the requests
+ with \l{RFC 6750}{bearer tokens}. Including the token in the
+ \l{RFC 6750 - Header Field}{HTTP \c Authorization header} is arguably
+ the most common.
\li Access token refreshing. Access tokens typically expire relatively
- quickly, say in one hour. If the application received a refresh token
- in addition to the access token, the refresh token can be used to
- request a new access token. Refresh tokens are long-lived and
applications
- can persist them to avoid the need for a new authorization stage
- (and thus another browser interaction).
+ quickly, for example, after one hour. If the application received a
+ refresh token in addition to the access token, the refresh token can be
+ used to request a new access token. Applications can persist
+ longer-lived refresh tokens to avoid the need for a new
+ authorization stage (and thus another browser interaction).
\endlist
-\section2 Details and Customization
+\section2 Details and customization
-OAuth2 flows are dynamic and following the details can
+OAuth 2.0 flows are dynamic and implementing the specifications can
be tricky at first. The figure below illustrates the main details
of a successful authorization code flow.
\image oauth2-codeflow-details.webp
+{Details of OAuth 2.0 flow showing the specific event calls}
-For clarity the figure omits some less used signals, but altogether
+For clarity, the figure omits some signals, but altogether
illustrates the details and main customization points. The customization
-points are the various signals/slots the application can catch (and call),
+points are the various signals and slots the application can use,
as well as the callbacks which are settable with
\l QAbstractOAuth::setModifyParametersFunction() and
\l QAbstractOAuth2::setNetworkRequestModifier().
-\section2 Choosing A Reply Handler
+\section2 Choosing a reply handler
-The decision on which reply hander to use, or to implement,
-is dependent on the
-\l {https://datatracker.ietf.org/doc/html/rfc6749#appendix-A.6}{redirect_uri}
-used. The \c redirect_uri is where the browser is redirected upon concluding
-the authorization stage.
-
-In the context of native applications,
-\l {https://datatracker.ietf.org/doc/html/rfc8252#section-7}
-{RFC 8252 outlines three main types of URI schemes}:
-\c loopback, \c https, and private-use.
+Deciding which handler to use depends on the
+\l{RFC 6749 - redirect_uri Syntax}{redirect_uri} element. The \c redirect_uri
+is set to where the browser is redirected upon concluding the authorization
+stage.
+
+For receiving the authorization response in native applications, \l{RFC 8252}
+specifies three main types of
+\l{RFC 8252 - Authorization Response in a Native App}{response URI schemes}:
+private-use, loopback, and https.
\list
- \li
\l{https://datatracker.ietf.org/doc/html/rfc8252#section-7.1}{Private-use URIs}:
+ \li \l{RFC 8252 - Private-Use URI Scheme Redirection}{Private-use URIs}:
Can be used if the OS allows an application to register a custom URI
scheme. An attempt to open an URL with such custom scheme will open the
related native application. See \l QOAuthUriSchemeReplyHandler.
- \li \l{https://datatracker.ietf.org/doc/html/rfc8252#section-7.2}{HTTPS
URIs}:
+ \li \l{RFC 8252 - Claimed https Scheme URI Redirection}{HTTPS URIs}:
Can be used if the OS allows the application to register a custom HTTPS
URL. An attempt to open this URL will open the related native
application. This scheme is recommended if the OS supports it.
See \l QOAuthUriSchemeReplyHandler.
- \li \l{https://datatracker.ietf.org/doc/html/rfc8252#section-7.3}{Loopback
Interfaces}:
+ \li \l{RFC 8252 - Loopback Interface Redirection}{Loopback Interfaces}:
These are commonly used for desktop applications, and applications
during development. The \l QOAuthHttpServerReplyHandler is designed to
handle these URIs by setting up a local server to handle the
@@ -195,194 +198,186 @@
\li Application-specific usability, security, and other requirements.
\endlist
-\quotation \l {https://datatracker.ietf.org/doc/html/rfc8252#section-7.2}
- {RFC 8252 recommends using the \c https scheme} for
-security and usability advantages over the other methods.
-\endquotation
-
-\section1 Device Authorization Flow
-
-The Device Authorization Flow is intended for connected devices that are
-limited in terms of input capabilities, or where user-agent/browser usage
-is not practical.
+\l{RFC 8252 - Claimed https Scheme URI Redirection}{RFC 8252} recommends using
+the \c https scheme for security and usability advantages over the other
+methods.
+
+\section1 OAuth 2.0 Device Authorization Grant
+
+\l{RFC 8628} OAuth 2.0 Device Authorization Grant is intended for connected
+devices that are limited in terms of input capabilities, or where
+user-agent-browser usage is not practical. Example devices that use this flow
+are smart appliances that need external devices for authorization.
-The following code snippet provides an example setup:
+Consider the following sample setup:
\snippet src_oauth_replyhandlers.cpp deviceflow-setup
\codeline
\snippet src_oauth_replyhandlers.cpp deviceflow-handle-authorizewithusercode
\codeline
\snippet src_oauth_replyhandlers.cpp deviceflow-handle-grant
-\section2 Stages
+\section2 Device Authorization Grant stages
-Device Authorization Flow has three main stages: initializing
+The Device Authorization Grant flow has three main stages: initializing
the authorization, polling for tokens, and completing the authorization.
These are optionally followed by token usage and token refreshing.
The following figure illustrates these stages:
\image oauth2-deviceflow-stages.webp
+{Simplified authorization grant flow in a Qt application using a browser on a
+separate device}
\list
\li Authorization is initialized by sending a HTTP request to
the authorization server. The authorization server provides a user
- code, verification URL(s), and a device code in response.
- \li After authorization is initialized, user is provided with
+ code, verification URLs, and a device code in response.
+ \li After authorization is initialized, the user is provided with
a user code and verification URL(s) for completing the authorization.
- Providing the information for the user is
- \l
{https://datatracker.ietf.org/doc/html/rfc8628#section-3.3}{use-case specific}:
- it can be a visible URL on the screen, QR code, an email, and so on.
- \li While waiting for a user to complete the authorization, the device flow
- polls the authorization server for tokens. The device code
+ The mechanism for the end user varies: it can be a visible URL on the
screen, QR code, an email, and so on.
+ Refer to \l{RFC 8628 - User Interaction} for more information.
+ \li While waiting for the end user to complete the authorization, the
+ device flow polls the authorization server for tokens. The device code
received in the previous step is used to match the authorization
session. The poll interval is decided by the authorization server,
and is typically 5 seconds.
- \li Once user has accepted (or denied) the authorization, the
+ \li Once the end user has accepted or denied the authorization, the
authorization server responds to a poll request with the requested
- tokens or an error code (in case of denial), and the authorization is
- complete.
+ tokens or an error code if denied, and the authorization is complete.
\endlist
-\section2 Details and Customization
+\section2 Details and customization
-The following figure illustrates the flow in more detail. The figure
-illustrates also the main customization points, which may sometimes
-be needed (for instance proprietary parameters, or additional
-authentication credentials).
+The following figure illustrates the device authorization grant flow in more
+detail. The figure shows the main customization points, which are sometimes
+necessary. For example, proprietary parameters, or additional
+authentication credentials.
\image oauth2-deviceflow-details.webp
+{Details of OAuth 2.0 device grant flow showing the specific event calls}
-\section1 Refreshing Tokens
-
-A full OAuth2 flow requires user interaction, which can be intrusive
-to the user experience. To minimize these interactions,
-tokens can be
-\l {https://datatracker.ietf.org/doc/html/rfc6749#section-6}
-{silently refreshed} from user's perspective.
+\section1 Refresh tokens
-Refreshing tokens requires that the authorization server provide a
-\l {https://datatracker.ietf.org/doc/html/rfc6749#section-1.5}{refresh token}
+Refreshing tokens require that the authorization server provide a
+\l{RFC 6749 - Refresh Token}{refresh token}
during authorization. Providing a refresh token is up to the
-authorization server: some servers provide it always, some never,
-and some provide it if a specific
-\l {QAbstractOAuth2::requestedScopeTokens}{scope} was present in the
+authorization server: some servers may choose to always provide it, some may
+never provide it, and some provide it if a specific
+\l{QAbstractOAuth2::requestedScopeTokens}{scope} was present in the
authorization request.
The following figure illustrates the token refresh in more detail:
\image oauth2-refresh-details.webp
+{Details of refreshing tokens showing the specific event calls}
As shown in the figure above, the usual customization points
are also available when refreshing tokens.
To refresh the tokens after an application startup,
the application needs to persist the refresh token securely,
-and set it with \l {QAbstractOAuth2::setRefreshToken()}.
-\l QAbstractOAuth2::refreshTokens() can
+and set it with \l QAbstractOAuth2::setRefreshToken.
+\l QAbstractOAuth2::refreshTokens can
then be called to request new tokens.
-Since Qt 6.9, applications can also use refresh convenience
-functionality to automatically refresh the tokens - see
-\l {QAbstractOAuth2::accessTokenAboutToExpire()},
-\l {QAbstractOAuth2::autoRefresh}, and
-\l {QAbstractOAuth2::refreshLeadTime}.
+New in Qt 6.9, applications can automatically refresh the tokens - see
+\l QAbstractOAuth2::accessTokenAboutToExpire,
+\l QAbstractOAuth2::autoRefresh, and
+\l QAbstractOAuth2::refreshLeadTime.
The expiration time for a refresh token is generally not indicated by
the authorization server (apart from the server's documentation).
-Their validity can range from days to months, or longer. Furthermore,
-as with other tokens, they can be revoked by the user and thus
+Their validity can range from days, months, or longer. Furthermore,
+as with other tokens, refresh tokens can be revoked by the user and thus
invalidated at any time. Therefore, it is important to properly detect a failed
refresh attempt with
-\l {QAbstractOAuth::requestFailed()} or
-\l {QAbstractOAuth2::serverReportedErrorOccurred()}.
+\l QAbstractOAuth::requestFailed or
+\l QAbstractOAuth2::serverReportedErrorOccurred.
+
+OAuth 2.0 flows require many user interaction, which can be intrusive
+to the user experience. To minimize these interactions,
+tokens can be silently refreshed for the user. Refer to the
+\l{RFC 6749 - Refreshing Access Tokens} for more information.
-\section1 Qt OpenID Connect Support
+\section1 Qt OpenID Connect support
-OpenID Connect (OIDC) is a
-\l {https://openid.net/specs/openid-connect-core-1_0-final.html}
-{simple identity layer on top of OAuth2 protocol}. Where authorization
-provides means to authorize users to perform actions, OIDC enables
-establishing a trusted identity of a user.
+\l{OpenID Connect Core}{OpenID Connect (OIDC)} is a simple identity layer on
+top of OAuth 2.0. OIDC can use an authorization server for authenticating the
+identity of a user. Accessing simple user profile information is also possible
+with OIDC.
Qt's support for OIDC is at the moment limited to getting
-\l
{https://openid.net/specs/openid-connect-core-1_0-final.html#Terminology}{ID
tokens}.
-An \c {ID token} is a
-\l {https://datatracker.ietf.org/doc/html/rfc7519}{JSON Web Token (JWT)}
-that contains claims about the authentication event.
+ID tokens. An ID token is a \l{JSON Web Token (JWT)} that contains claims about
+the authentication event.
-Notably the support for \c {ID token} validation or \c {ID token}
-decryption is currently not implemented.
+\note ID token validation or ID token decryption is currently not implemented.
+You must use a \l{Third-party JWT Libraries}{third-party JWT library} for JWT
+token signing or verification.
-Assuming the application is able to \l {Validating an ID Token}{validate}
+Assuming the application is able to \l{Validating an ID Token}{validate}
the received tokens, the token can be used to establish
-the identity of the user reliably (to the degree the OIDC provider itself
+the identity of the user reliably (so long as the OIDC provider itself
is trusted).
-ID tokens are sensitive information and should be kept as a secret.
-ID tokens are not intended for sending out in API
-calls - the access token is intended for that purpose. Note that some
-vendors may use the same
-\l {https://datatracker.ietf.org/doc/html/rfc7519}{JWT format} for access
-tokens, but that is not to be confused with actual ID tokens which
-incidentally use the same format. With ID tokens the client receiving
-the token is responsible for verifying the token, whereas with access
-tokens it's the resource server accepting the token that is responsible
-for verification.
-
-\section2 Getting an ID Token
-
-Getting an ID token is very similar to getting an access token.
-First we need to set the appropriate scope. Authorization Server
-vendor may support additional scope specifiers such as \c {profile}
-and \c {email}, but all OIDC requests must include \c {openid} scope:
+ID tokens are sensitive information and should be kept as a secret and
+are not the same as access tokens. ID tokens are not intended for sending out
+in API calls - the access token is intended for that purpose. Note that some
+vendors may use the same JWT format for access tokens, but that is not to be
+confused with actual ID tokens which use the same format. With ID
+tokens, the client receiving the token is responsible for verifying the token,
+whereas with access tokens it's the resource server accepting the token that is
+responsible for verification.
+
+\section2 Getting an ID token
+
+Getting an ID token is similar to getting an access token.
+First, we need to set the appropriate scope. The authorization Server
+vendor may support additional scope specifiers such as \c{profile}
+and \c{email}, but all OIDC requests must include \c{openid} scope:
\snippet src_oauth_replyhandlers.cpp oidc-setting-scope
-For OIDC it is strongly recommended to use
-\l {QAbstractOAuth2::nonce}{nonce} parameter.
+For OIDC, it is strongly recommended to use
+\l{QAbstractOAuth2::nonce}{nonce} parameter.
This is done by ensuring that appropriate
-\l {QAbstractOAuth2::NonceMode}{NonceMode} is set.
+\l{QAbstractOAuth2::NonceMode}{NonceMode} is set.
\snippet src_oauth_replyhandlers.cpp oidc-setting-nonce-mode
-As last step we can listen for either \l {QAbstractOAuth2::granted}
-signal or the \l {QAbstractOAuth2::idTokenChanged} directly:
+As the last step, we can listen for either \l QAbstractOAuth2::granted
+signal or the \l QAbstractOAuth2::idTokenChanged directly:
\snippet src_oauth_replyhandlers.cpp oidc-listen-idtoken-change
-\section2 Validating an ID Token
+\section2 Validating an ID token
-Validating the received ID Token is a crucial part of the
-flow, and,
-\l
{https://openid.net/specs/openid-connect-core-1_0-final.html#IDTokenValidation}
-{when fully implemented, a somewhat complicated task}.
+Validating the received ID Token is a critical part of the
+authentication flow, and when fully implemented, a somewhat complicated task.
+Refer to the full at \l{OpenID Connect ID Validation}.
-At its outline validation consists of these steps
+As a small summary, validation consists of these steps:
\list
\li Decrypting the token if needed
- (\l {https://datatracker.ietf.org/doc/html/rfc7516}{see JWE})
+ (\l{JSON Web Encryption (JWE)}{see JWE})
\li Extracting the token header, payload, and signature
\li Validating the signature
\li Validating the fields of the payload
- (such as \c {aud, iss, exp, nonce, iat})
+ (such as \c{aud, iss, exp, nonce, iat})
\endlist
Qt currently doesn't provide support for ID token validation,
but there are
-\l {https://jwt.io/libraries}{several C++ library options available},
-such as
-\l {https://github.com/Thalhammer/jwt-cpp}{jwt-cpp}.
+\l{Third-party JWT Libraries}{Third-party JWT libraries},
+such as \l{jwt-cpp}.
-\section3 ID Token Verification Example
+\section3 ID Token Verification example
-This section illustrates a simple verification with the help of
-\l {https://github.com/Thalhammer/jwt-cpp}{jwt-cpp} library.
+This section illustrates a simple verification example.
As prerequisites, the development environment needs to have
-\l {https://www.openssl.org/}{OpenSSL} libraries, and
-\l {https://github.com/Thalhammer/jwt-cpp}{jwt-cpp} include
+\l{OpenSSL Toolkit}{OpenSSL} libraries, and \l{jwt-cpp} in the include
folder under the application project's source directory.
-In application project's \c {CMakeLists.txt} we first check
-that the prerequisities are met:
+In application project's \c CMakeLists.txt file, we first check
+that the pre-requisities are met:
\snippet ../snippets/CMakeLists.txt oidc-jwt-cpp-available-cmake
Then we add necessary includes and libraries:
@@ -391,91 +386,80 @@
In the application source files, include the verification library:
\snippet src_oauth_replyhandlers.cpp oidc-jwt-cpp-include
-Once the application receives an \c {ID token}, it's time to verify it.
-First we find a matching key from JSON Web Key Sets (JWKS, see
-\l {OpenID Connect Discovery}).
+Once the application receives an ID token, it's time to verify it.
+First we find a matching key from JSON Web Key Sets (JWKS), see
+\l{OpenID Connect Discovery}).
\snippet src_oauth_replyhandlers.cpp oidc-jwt-cpp-key-matching
And then we do the actual verification:
\snippet src_oauth_replyhandlers.cpp oidc-jwt-cpp-verification
-It is recommended to check up-to-date documentation and examples
-of the library being used, and also to familiarize with
-\l
{https://openid.net/specs/openid-connect-core-1_0-final.html#IDTokenValidation}
-{ID token verification}.
-
-\section2 Reading ID Token Values
-
-The ID token is in
-\l {https://datatracker.ietf.org/doc/html/rfc7519}{JSON Web Token (JWT)}
-format and consists of a header, payload, and signature parts,
-separated by dots \{'.'}.
+\section2 Reading ID token values
+
+The ID token is in \l{JSON Web Token (JWT)} format and consists of a header,
+payload, and signature parts, separated by dots \c {.}.
Reading the values of the ID token is straightforward. As an example,
-assuming a struct:
+assume that there is a struct:
\snippet src_oauth_replyhandlers_p.h oidc-id-token-struct
And a function:
\snippet src_oauth_replyhandlers_p.h oidc-id-token-parser-declaration
-The token can be extracted:
+The token can be extracted with:
\snippet src_oauth_replyhandlers.cpp oidc-id-token-parsing
-In more rare cases the token may be encrypted with
-\l {https://datatracker.ietf.org/doc/html/rfc7516}{JSON Web Encryption (JWE)},
-which internally contains a JWT token. In this case the token must
+In some cases the token may be encrypted as \l{JSON Web Encryption (JWE)}
+which internally contains a JWT token. In this case, the token must
be decrypted first.
\section2 OpenID Connect Discovery
-\l {https://openid.net/specs/openid-connect-discovery-1_0.html}
-{OpenID Connect Discovery} defines means to discover needed
+\l{OpenID Connect Discovery} defines the means to discover needed
OpenID provider details, in order to interact with it. This includes
-things such as \c {authorization_endpoint} and \c {token_endpoint} URLs.
+information such as \c authorization_endpoint and \c token_endpoint URLs.
While these provider details can be statically configured in the application,
discovering the details at runtime may provide more flexibility and
robustness in interacting with various providers.
-Getting the discovery document is a simple \c {HTTP GET} request.
+Getting the discovery document is a simple HTTP GET request.
The document is typically located in
-\c {https://<the-domain eg. example.com>/.well-known/openid_configuration}
+\c{https://<domain name>/.well-known/openid_configuration}.
\snippet src_oauth_replyhandlers.cpp oidc-get-openid-configuration
-Notably, for token validation, the
-\l {https://datatracker.ietf.org/doc/html/rfc7517#section-5}{jwks_uri} field
-provides a link for accessing the current (public) security credentials.
-Using that removes the need to hardcode such credentials in the application
+Notably, for token validation, the \l{JSON Web Key (JWK) Set Format}{jwks_uri}
+field provides a link for accessing the current (public) security credentials.
+Using that removes the need to hard-code such credentials in the application
directly. This also helps with key rotation; the vendors may change the used
keys from time to time, and therefore ensuring an up-to-date key is important.
-Getting the keys is similarly a simple \c {HTTP GET} request:
+Getting the keys is similarly a simple HTTP GET request:
\snippet src_oauth_replyhandlers.cpp oidc-get-jwks-keys
The key set typically contains several keys. The correct key is indicated
in the JWT header (care must be taken to match the keys properly, just
-checking the key id (\c {kid}) field is not adequate).
+checking the key id, \c{kid}, field is not adequate).
\section2 OpenID UserInfo Endpoint
An alternative way to access user information is to use
-\l {https://openid.net/specs/openid-connect-core-1_0-final.html#UserInfo}
-{OpenID UserInfo Endpoint}, if the OIDC provider supports it. The URL
-for the userinfo is in \c {userinfo_endpoint} field of the
-\l {OpenID Connect Discovery} document.
-
-The userinfo endpoint does not use the ID token, but is
-accessed with the access token. Accessing the userinfo is similar
-to accessing any other resource with an access token.
+\l{OpenID Connect UserInfo Endpoint}, if the OIDC provider supports it. The URL
+for the userinfo is in \c userinfo_endpoint field of the
+\l{OpenID Connect Discovery} document.
+
+The UserInfo endpoint does not use the ID token, but is accessed with the
+access token. Accessing the UserInfo is similar to accessing any other resource
+with an access token.
Assuming the access token is received and set for example by:
\snippet src_oauth_replyhandlers.cpp oidc-set-bearertoken
-Then accessing the userinfo is a \c {HTTP GET} request:
+Then accessing the UserInfo is a HTTP GET request:
\snippet src_oauth_replyhandlers.cpp oidc-read-userinfo
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/qtnetworkauth-everywhere-src-6.9.2/src/oauth/doc/src/qtnetworkauth.qdoc
new/qtnetworkauth-everywhere-src-6.10.0/src/oauth/doc/src/qtnetworkauth.qdoc
--- old/qtnetworkauth-everywhere-src-6.9.2/src/oauth/doc/src/qtnetworkauth.qdoc
2025-08-17 21:32:14.000000000 +0200
+++
new/qtnetworkauth-everywhere-src-6.10.0/src/oauth/doc/src/qtnetworkauth.qdoc
2025-10-01 20:34:32.000000000 +0200
@@ -7,11 +7,15 @@
\brief Provides network authorization capabilities (OAuth).
Qt Network Authorization provides a set of APIs that enable Qt
- applications to obtain limited access to online accounts and
- HTTP services without exposing users' passwords.
-
- Currently, the supported authorization protocol is \l {https://oauth.net}
- {OAuth}, versions 1 and 2.
+ applications to implement common authorization and authentication
protocols.
+ For example, an application can implement access controls such as providing
+ limited access to online accounts and HTTP services without exposing user
+ passwords.
+
+ This module focuses on \l{OAuth 2.0} and provides limited support for
+ \l{OpenID}. Refer to the section below about
+ \l{Supported Authorization and Authentication Protocols}
+ {supported protocols}.
\section1 Using the Module
@@ -40,31 +44,28 @@
QT += networkauth
\endcode
- \section1 Overview
-
- The goal of this module is to provide a way to handle different
- authentication methods present on the Internet.
+ \section1 Supported Authorization and Authentication Protocols
- There are several authentication systems, including:
+ Qt Network Authorization module supports functionalities from:
\list
- \li \l {https://datatracker.ietf.org/doc/html/rfc5849} {OAuth 1}
- \li \l {https://datatracker.ietf.org/doc/html/rfc6749} {OAuth 2}
- \li \l {http://openid.net} {OpenID}
- \li \l {http://openid.net/connect/} {OpenID Connect}
+ \li \l {OAuth 1}
+ \li \l {OAuth 2.0}
+ \li \l {OpenID}
+ \li \l {OpenID Connect}
\endlist
- These systems allow the application developers to create applications which
- use external authentication servers provided by an
- \e {Authorization Server}.
- Users of these services need not worry about passing their credentials to
- suspicious applications. Instead, the credentials are entered in a known
- and trusted web interface.
+ These systems use a trusted \e {authorization server} for issuing access
+ tokens so that users do not send credentials to resources and resource
+ owners do not directly manage user credentials. For example, a user of a
+ cloud-based photo album website does not have to worry about passing their
+ credentials to the website. Instead, the credentials are
+ managed by a trusted authorization service through a web interface.
\section1 Articles and Guides
\list
- \li \l {Qt OAuth2 Overview}
+ \li \l {OAuth 2.0 Overview}
\li \l {Qt OAuth2 Browser Support}
\endlist
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/qtnetworkauth-everywhere-src-6.9.2/src/oauth/qabstractoauth2.cpp
new/qtnetworkauth-everywhere-src-6.10.0/src/oauth/qabstractoauth2.cpp
--- old/qtnetworkauth-everywhere-src-6.9.2/src/oauth/qabstractoauth2.cpp
2025-08-17 21:32:14.000000000 +0200
+++ new/qtnetworkauth-everywhere-src-6.10.0/src/oauth/qabstractoauth2.cpp
2025-10-01 20:34:32.000000000 +0200
@@ -190,7 +190,7 @@
\value Enabled Nonce is sent during authorization stage.
\value Disabled Nonce is not sent during authorization stage.
- \sa nonce, {Qt OAuth2 Overview}
+ \sa nonce, {OAuth 2.0 Overview}
*/
/*!
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/qtnetworkauth-everywhere-src-6.9.2/src/oauth/qoauth2authorizationcodeflow.cpp
new/qtnetworkauth-everywhere-src-6.10.0/src/oauth/qoauth2authorizationcodeflow.cpp
---
old/qtnetworkauth-everywhere-src-6.9.2/src/oauth/qoauth2authorizationcodeflow.cpp
2025-08-17 21:32:14.000000000 +0200
+++
new/qtnetworkauth-everywhere-src-6.10.0/src/oauth/qoauth2authorizationcodeflow.cpp
2025-10-01 20:34:32.000000000 +0200
@@ -39,7 +39,7 @@
user will need access to a web browser.
As a redirection-based flow this class requires a proper
- reply handler to be set. See \l {Qt OAuth2 Overview},
+ reply handler to be set. See \l {OAuth 2.0 Overview},
QOAuthHttpServerReplyHandler, and QOAuthUriSchemeReplyHandler.
*/
