Fix device code login to send empty client_id

RSTS bakes its built-in ApplicationClientId into the JWT clientIdClaim
when the user completes the flow via the verification_uri_complete URL
(LoginController.ProcessDeviceLogin reads client_id from the query
string, but verification_uri_complete contains no client_id query param,
and Login.js skips StartDeviceCodeFlow when device= is already in the
URL, so the cached client_id never gets re-injected). The polling check
in OAuthTokenManager.CreateAccessTokenFromAuthCode then compares the
baked-in ApplicationClientId against the cached client_id we sent, and
rejects with invalid_request.

Sending an empty client_id makes RSTS normalize both sides to
ApplicationClientId, so both browser flows (verification_uri_complete
and manual user_code entry) succeed end-to-end.

Non-empty client_id values still work, but only when the appliance has
a matching RelyingPartyApplication registered. Documented this caveat
on DeviceCodeLoginParameters.ClientId.

Author: petrsnd

SafeguardDotNet.DeviceCodeLogin/DeviceCodeLogin.cs

@@ -70,9 +70,17 @@ public static async Task<ISafeguardConnection> ConnectAsync(
             throw new ArgumentException("DisplayCallback is required.", nameof(parameters));
         }
 
-        var clientId = parameters.ClientId ?? "SafeguardDotNet";
+        var clientId = parameters.ClientId ?? string.Empty;
         var scope = parameters.Scope ?? "rsts:sts:primaryproviderid:local";
 
+        // RSTS normalizes empty client_id to its built-in ApplicationClientId in
+        // both the device-code cache (OAuthTokenManager.GetDeviceCode) and the
+        // browser-completion path (LoginController.ProcessDeviceLogin). When the
+        // user finishes via verification_uri_complete, RSTS never propagates a
+        // non-empty cached client_id to the auth code; the JWT clientIdClaim is
+        // baked as ApplicationClientId. Sending an empty client_id here makes
+        // the polling-side comparison value also normalize to ApplicationClientId,
+        // so both browser flows succeed end-to-end.
         using var http = Safeguard.AgentBasedLoginUtils.CreateStatelessHttpClient(ignoreSsl);
 
         // Step 1: Request device code (CRITICAL: no trailing slash on URL)

SafeguardDotNet.DeviceCodeLogin/DeviceCodeLoginParameters.cs

@@ -26,10 +26,15 @@ public class DeviceCodeLoginParameters
 
     /// <summary>
     /// OAuth2 client identifier for the device authorization request.
-    /// Default: "SafeguardDotNet". Only change if the appliance has
-    /// RelyingPartyApplications configured with a specific client_id.
+    /// Defaults to empty, which RSTS normalizes to its built-in
+    /// ApplicationClientId. Only set this when the appliance has a
+    /// RelyingPartyApplication registered with a matching client_id; any
+    /// other non-empty value will fail token redemption when the user
+    /// completes the flow via the verification_uri_complete URL because
+    /// RSTS bakes ApplicationClientId into the auth code in that path
+    /// while comparing it to the cached client_id during polling.
     /// </summary>
-    public string ClientId { get; set; } = "SafeguardDotNet";
+    public string ClientId { get; set; } = string.Empty;
 
     /// <summary>
     /// Polling interval in seconds between token requests. Default: 5 (RFC 8628 default).