Merge pull request #233 from petrsnd/bugfix/petrsnd/device-code-empty-client-id

Fix device code login: default to empty client_id so token redemption succeeds

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).