桌面应用及其内嵌WebView的IdentityServer4合法身份认证方案咨询

Alright, let's break down this scenario and walk through a valid authentication implementation step by step. I’ve worked with similar setups combining IdentityServer4, Qt’s QWebEngineView, and hybrid desktop/web apps, so here’s a practical, secure approach tailored to your needs:

First, let’s align on the key roles to avoid confusion:

• IdentityServer4 Instance: The central authentication authority.
• Desktop App: Acts as both an ApiResource (exposes its own backend services) and a container for the web app. It uses ResourceOwnerPasswordAndClientCredentials to fetch tokens.
• Web App: Registered as an IdentityServer4.Models.Client, runs inside the desktop app’s QWebEngineView, and needs to communicate with backend APIs.

1. IdentityServer4 Configuration #

Start by ensuring your Client and ApiResource configurations are correctly set up to support the hybrid desktop/web flow:

Web App Client Configuration #

Since the web app runs inside a controlled desktop WebView, we can configure it with the required grant types, scopes, and security settings:

new Client
{
    ClientId = "web-app-in-desktop",
    ClientName = "Web App Hosted in Desktop WebView",
    AllowedGrantTypes = GrantTypes.ResourceOwnerPasswordAndClientCredentials,
    ClientSecrets = { new Secret("your-web-app-secret-here".Sha256()) },
    AllowedScopes = { "desktop-api-scope", "other-required-api-scopes" },
    AllowedCorsOrigins = { "http://your-web-app-local-url" }, // Match your web app's runtime address
    AllowOfflineAccess = true, // Enable refresh tokens to avoid re-authenticating users
    AccessTokenLifetime = 3600, // 1-hour access token (adjust based on your security needs)
    RefreshTokenLifetime = 2592000 // 30-day refresh token
}

Desktop App ApiResource Configuration #

Register your desktop app’s backend as an API resource to protect its endpoints:

new ApiResource("desktop-api-resource", "Desktop Application Backend")
{
    Scopes = { "desktop-api-scope" },
    ApiSecrets = { new Secret("your-desktop-api-secret-here".Sha256()) }
}

2. Desktop App (Qt QWebEngineView) Handling #

The desktop app is the trusted container—all token management should happen here, not in the web app, to keep sensitive credentials secure.

Step 2.1: Fetch Access Tokens #

Use the ResourceOwnerPassword grant type to collect user credentials (username/password) and request tokens from IdentityServer4’s /connect/token endpoint. Here’s a simplified Qt C++ example:

QUrl tokenEndpoint("https://your-identity-server-url/connect/token");
QNetworkRequest request(tokenEndpoint);
request.setHeader(QNetworkRequest::ContentTypeHeader, "application/x-www-form-urlencoded");

QByteArray postData;
postData.append("grant_type=password");
postData.append("&client_id=desktop-app-client-id"); // Your desktop app's client ID
postData.append("&client_secret=desktop-app-secret");
postData.append("&username=" + QUrl::toPercentEncoding(userInputUsername));
postData.append("&password=" + QUrl::toPercentEncoding(userInputPassword));
postData.append("&scope=desktop-api-scope other-required-api-scopes");

QNetworkAccessManager* authManager = new QNetworkAccessManager(this);
connect(authManager, &QNetworkAccessManager::finished, this, [=](QNetworkReply* reply) {
    if (reply->error() == QNetworkReply::NoError) {
        QJsonDocument tokenDoc = QJsonDocument::fromJson(reply->readAll());
        QJsonObject tokenData = tokenDoc.object();
        QString accessToken = tokenData["access_token"].toString();
        QString refreshToken = tokenData["refresh_token"].toString();

        // Securely store refresh token (use QKeychain or system-level keychain)
        saveRefreshTokenToSecureStorage(refreshToken);
        // Pass access token to the web app
        injectTokenIntoWebView(accessToken);
    }
});
authManager->post(request, postData);

Step 2.2: Inject Token into WebView #

The safest way to pass the token to the web app is via Qt’s QWebChannel (enables secure C++ ↔ JavaScript communication):

// Desktop app C++ side
QWebChannel* webChannel = new QWebChannel(this);
// Register an auth service object that exposes the access token
webChannel->registerObject("desktopAuthService", this);
yourWebView->page()->setWebChannel(webChannel);

// Web app JavaScript side
new QWebChannel(qt.webChannelTransport, function(channel) {
    const authService = channel.objects.desktopAuthService;
    const accessToken = authService.getAccessToken(); // Call C++ method to fetch token
    // Configure your HTTP client to use the token for all API requests
    axios.defaults.headers.common['Authorization'] = `Bearer ${accessToken}`;
});

Step 2.3: Handle Token Refresh #

When the access token expires, use the stored refresh token to fetch a new one without user input:

// Example refresh token request
QByteArray refreshPostData;
refreshPostData.append("grant_type=refresh_token");
refreshPostData.append("&client_id=desktop-app-client-id");
refreshPostData.append("&client_secret=desktop-app-secret");
refreshPostData.append("&refresh_token=" + QUrl::toPercentEncoding(storedRefreshToken));

// Send request, parse new access token, and re-inject it into the web view

3. Web App Implementation #

The web app only needs to consume the token provided by the desktop app:

• Attach the Authorization: Bearer {accessToken} header to all API requests.
• Listen for 401 Unauthorized responses, and trigger a token refresh request to the desktop app via QWebChannel.
• Never store sensitive tokens (like refresh tokens) in the web app’s local storage or cookies—leave all token management to the desktop app.

4. Critical Security Best Practices #

• Secure Token Storage: Use Qt’s QKeychain or system-specific keychains (Windows Credential Manager, macOS Keychain) to store refresh tokens—never store them in plaintext files.
• WebView Hardening: Disable unnecessary QWebEngineView features (e.g., pop-ups, file access) and restrict navigation to trusted domains only.
• Enforce HTTPS: All communication (IdentityServer4, APIs, web app) must use HTTPS to prevent token interception.
• Least Privilege: Restrict the web app’s AllowedScopes to only the APIs it actually needs to access.
• Short-Lived Access Tokens: Keep access token lifetimes short (1 hour is a good default) to minimize risk if a token is leaked.

内容的提问来源于stack exchange，提问作者Babak