Qt Network Authorization モジュールは、8年前の Qt 5.8 でリリースされました。 それ以来、OAuth2 の役割と用途は大幅に拡大しています。 今日では、多くの人が何らかの形で OAuth2 を使用しています。「Sign-in with ...」ボタンをクリックしたり、お気に入りのオンライン描画アプリケーションでクラウドドライブに結果を保存したりといった方法です。Qt 5.8 の時代から、いくつかの新しい規格が導入されたり、大きな注目を集めたりしてきました。 これらに対応するために、Qt 6.8 および今後リリース予定の Qt 6.9 では、いくつかの新機能、バグ修正、ドキュメントの改善が導入されています。
この記事では、そのハイライトを紹介します。
Qt 6.8: 品質、セキュリティ、ドキュメントの改善
Qt 6.8 のリリースは、ユーザーからのフィードバックに基づいて Qt Network Authorization モジュールの改善に重点的に取り組んだものでした。Qt Bug Report に寄せられたバグや提案は体系的に整理され、対応された結果、多くの修正と機能強化が実現しました。 いくつかの注目すべき変更点を見てみましょう。
概要ドキュメント
OAuth2の使い始めは、最初は少し難しいかもしれません。 これを支援するために、モジュールには概要ドキュメントが追加され、入門としても役立ちます。 ドキュメントはこちら（Qt 6.9バージョン）でご覧いただけます。
PKCE – 小さな、しかし重要なセキュリティ強化
PKCE（Proof Key for Code Exchange）は、承認コードハイジャックの影響を軽減するセキュリティ手法であり、特に承認コード付与（QOAuth2AuthorizationCodeFlow）において重要です。 PKCEはQt 6.8からサポートされており、デフォルトで有効になっています。 必要に応じて、デフォルトの動作を調整することも可能です。この列挙型と関連するセッターを参照してください。
モバイルプラットフォームにおけるリダイレクトサポートの改善
ネイティブアプリケーションにおける課題の1つは、OAuth2リダイレクトの処理です。認証サーバーが認証を完了した際、結果をユーザーのブラウザにリダイレクトする先はどこにするべきでしょうか？これはWeb開発とは異なります。Web開発では、ほぼ定義上、使用できるリダイレクトURLが存在します。
ネイティブアプリケーションの主な解決策は、localhostのウェブサーバーを使用することです。これは、アプリケーション自体と同じデバイス上で実行されます。これが、Qt Network Authorizationが当初からサポートしているものです。ネイティブアプリケーションのベストプラクティスであるRFCは、この方式を推奨していますが、いくつかの欠点もあります。特に、商用認証サーバープロバイダーは、このようなローカルホストのリダイレクトの使用に制限を課す可能性があります。
この目的のために、Qt 6.8では新しい返信ハンドラクラスのQOAuthUriSchemeReplyHandlerが導入されました。この新しいハンドラは、カスタムURLスキーム（例えばcom.example.myapp://）やhttpsの処理が可能です。
これらは、オペレーティングシステムが対応するプラットフォーム（macOS、iOS、Android）でサポートされています。これを使用することで、認証サーバーの適合性、セキュリティ、ユーザーエクスペリエンスの面でいくつかの利点が得られます。オペレーティングシステムは、アプリケーションが特定のスキームに登録されていることを認識しているため、リダイレクト時にアプリケーションにフォーカスを戻すことができます。
サポート対象プラットフォームに関する注記として、Windowsデスクトップ[0]やLinuxデスクトップでは、システムレジストリの変更やxdg-mimeの使用を伴わない同様のオペレーティングシステムレベルのサポートは存在しないようです。そのため、Qt Network Authライブラリでのサポートは困難です[1]。しかし、これまで見落としていた方法があれば、ぜひお知らせください。
Qt 6.9: 機能アップデート
次期 Qt 6.9 の焦点は、新機能の追加とシステムの利便性向上です。
デバイス認証フロー
Qt 6.9 では、デバイス認証付与（Device Authorization Grant）と呼ばれる新しい認証フローが導入されます。 このフローは、比較的新しい RFC の追加であり、広くサポートされています。 このフローは、入力機能が限られている（または全くない）デバイスを対象としています。 これには、テレビ、HMI、IoT デバイスなどが含まれます。既存の承認コードフローとの大きな違いは、ユーザーが他のデバイス（電話、ラップトップなど）でアクセスを承認し、制限されたデバイスでのリダイレクト処理が不要であることです。
具体的な例としては、ユーザーが電話で読み取るためのQRコードを表示するテレビ画面があります。ユーザーはQRコードを読み取った後、その電話で承認を完了します。その後、テレビ（または他のデバイス）がサーバーから承認結果を取得します。
詳細は、QOAuth2DeviceAuthorizationFlowを参照してください。
OpenID Connect トークンの取得
OAuth2 は主に認証（authorization）、つまりアプリケーションにリソースへのアクセス権を与えることを目的としています。これに対して、OpenID Connect (OIDC) は認証（authentication）、つまりアプリケーションに信頼できるユーザーの ID を提供することを目的としています。OIDC は、シングルサインオンソリューションや「Sign-in With ...」ボタンなど、さまざまな用途で広く使用されています。
技術的には、OIDCはOAuth2の上に追加された薄いレイヤーです。Qt 6.9では、ユーザーのアイデンティティを含むIDトークンを取得するための基本機能が追加されました。
OIDCのサポートはQt 6.9では完全ではないことに注意してください。特に、現時点ではQtはIDトークンの検証をそのままの状態では提供していません。しかし、サードパーティライブラリを使用してこれを実現する方法を、例を挙げて文書化しています。概要のドキュメントを参照してください。
Qt 6.9 における私たちの主な目標は、OIDC（制限付きではありますが）を使用できるようにすることでした。OIDC に関するフィードバックがありましたら、こちらまたはQTBUG-129383 にコメントを残してください。
Qt WebEngine をユーザーエージェントとして使用
OAuth2では、認証にシステムブラウザを通常使用し、推奨されることもよくあります。しかし、アプリケーションに組み込まれたユーザーエージェントを使用する方が理にかなう場合もあります（詳細はOAuth2 Browser Supportのドキュメントを参照してください）。Qt 6.9では、Qt WebEngineなど、システムブラウザ以外のユーザーエージェントを使用しやすくなっています。
トークン更新の利便性
アクセストークンは通常、1時間以内のみ有効です。認証サーバーがリフレッシュトークンを提供している場合、ユーザーの操作なしでアクセストークンをリフレッシュするために使用できます。Qt 6.9では、トークンが期限切れに近づくと発行される新しいシグナル、QAbstractOAuth2::accessTokenAboutToExpire()が追加されました。
refreshLeadTimeプロパティを使用して、発行時間を微調整できます。また、autoRefreshプロパティをtrueに設定することで、自動更新を有効にすることもできます。
要求されたスコープと付与されたスコープの分離
OAuth2認証リクエストでは、スコープはアプリケーションがアクセスを希望するリソースを定義します。しかし、リクエストされたスコープと実際に付与されたスコープは異なる場合があります。ユーザーが部分的なアクセス権のみを承認している場合や、認証サーバーのポリシーが変更を強制する場合があります。
そのため、アプリケーションは実際に許可されたものを確認し、それに応じてアプリケーションの動作を調整することが重要です。これを支援するために、Qt 6.9 では requestedScope と grantedScope という 2 つの新しいプロパティが追加されました。Qt 6.9 以前では、単一の scopeプロパティが 2 つの役割を兼ねていましたが、このプロパティがどのような意味を持つのかが不明確でした。
ネットワークリクエストの変更
OAuth2では、複数のHTTPリクエスト（トークンのリクエスト、リフレッシュ、ポーリング、および新しいデバイスフローの場合の認証の開始）が発生します。Qtネットワーク認証では、リクエストパラメータを常に調整することは可能でしたが、リクエスト自体の変更はそれほど簡単ではありませんでした。
認証サーバーが、例えば特定のHTTPヘッダーをリクエストに含めることを期待している場合、この機能は非常に重要になります。これらはユースケース固有のヘッダーであったり、単に追加の認証ヘッダーであったりします。
Qt 6.9では、ネットワークリクエストを送信前にカスタマイズできるようにすることで、このニーズに対応しています。詳細はsetNetworkRequestModifier()を参照してください。
開発時のHTTPSリダイレクトハンドラー
Qt 6.9 で導入されたリクエスト機能の 1 つに、https localhost 応答ハンドラを使用する機能があります。これは開発時のテストや、管理された環境でのプロビジョニングに役立つはずです（詳細は こちらを参照してください）。
手動リダイレクト URL のホスト名の定義
localhostウェブサーバーを使用して認証サーバーからのリダイレクトを処理する場合、ホスト名を決定する必要があります。localhost にするべきでしょうか？ それとも 127.0.0.1 でしょうか？ それとも [::1] でしょうか？ これは意外にも多面的なトピックであり、ここでは取り上げませんが、詳細と関連する Qt 6.8 および Qt 6.9 の変更については こちらと こちらを参照してください。 これらの変更は、妥当なデフォルト値を提供することを目的としていますが、必要に応じて上書きすることも可能です。
Qt 6.9 では、実際の IP アドレスに関係なく、手動でホスト名を指定する方法が追加されました。
まとめ
個人的には、この 2 つの Qt リリース（Qt 6.8 と Qt 6.9）が Qt の OAuth2 分野を大きく前進させたことに非常に満足しています。 バグ修正、ドキュメントの改善、新機能はそれぞれ単独では些細なことのように思えるかもしれませんが、それらを合わせることで開発者のエクスペリエンスが大幅に改善されることを期待しています。
