Device authorization flow never sends client_secret, so netbird ssh / netbird login fail against Google

[Donemmanuelo]

Describe the problem

With a self-hosted (split) deployment whose DeviceAuthorizationFlow uses Google
directly (Provider: "hosted", a TVs and Limited Input devices OAuth client,
ClientSecret set), the device flow can never complete. The device code is issued, but
the very first token poll is rejected by Google, before the user has approved anything:

Error: dial <peer>:22: request JWT token: wait for JWT token:
  rpc error: code = Internal desc = failed to get token:
  Missing required parameter: client_secret

DeviceAuthorizationFlow.requestToken (client/internal/auth/device_flow.go) builds the
token form with only client_id, grant_type and device_code. The secret is
configured in management.json, sent by management in GetDeviceAuthorizationFlow, and
stored by the client in DeviceAuthProviderConfig.ClientSecret — but never put on the
wire. Google documents client_secret as a parameter of the device token poll
(https://developers.google.com/identity/protocols/oauth2/limited-input-device#step-4:-poll-googles-authorization-server).

The PKCE flow is not affected: it passes the secret through oauth2.Config, which is why
the same deployment works from macOS/Windows or a Linux desktop session. It only bites
where shouldUseDeviceFlow picks the device flow — headless Linux/FreeBSD, i.e. servers.

To reproduce

1. Split deployment, management v0.79.0/v0.80.0, Google as the direct IdP.
2. DeviceAuthorizationFlow: Provider: "hosted", ClientID/Audience = a Google
   TVs and Limited Input devices client, ClientSecret = its secret.
3. From a headless Linux peer (v0.80.0): netbird ssh root@<peer> whoami.
4. A user code is printed; the command fails immediately with the error above.

Expected behavior

When the device-flow provider config carries a client secret, the token poll includes
it; when it does not, nothing changes for public clients (Dex, Keycloak, Zitadel, ...).

Proposed fix

Three lines in requestToken, guarded so public clients are unaffected:

if d.providerConfig.ClientSecret != "" {
    form.Add("client_secret", d.providerConfig.ClientSecret)
}

I have this with a unit test that fails without the change, and verified it end-to-end
against Google with a patched v0.80.0 client: netbird ssh completed with
Authentication successful! and ran the remote command (for that test I also widened
the JWT wait locally — see the 30-second point below). Happy to open the PR once the
direction is agreed.

I am aware ProviderConfig.client_secret is deprecated in the proto and the docs now
recommend the embedded IdP with Google as a connector. If the intended answer is
"migrate to the embedded IdP", it would help to say so in the legacy Google docs and to
stop advertising a device flow that cannot work — today the secret is accepted, sent to
the client, and silently dropped.

Smaller, related: Google's device-code response uses verification_url (not RFC 8628's
verification_uri), so AuthFlowInfo unmarshals an empty URL and the CLI prints a blank
login link. The user code still works at https://www.google.com/device. I have a
separate small fix for that too (RFC names keep precedence), also tested live.

Also related, and IdP-independent: dialWithJWT (client/ssh/client/client.go) derives
the JWT context from the SSH dial timeout (ssh.ClientConfig.Timeout, 30 s), so the
whole device flow — including the human approving the code on another device — must
finish within 30 seconds or the CLI fails with DeadlineExceeded while the daemon is
still polling. The device code itself is valid for 30 minutes.

Environment

• Management v0.79.0 (split deployment), client v0.80.0 (netbirdio/netbird image), Linux
• Same code on current main

[mlsmaycon]

Hello @Donemmanuelo we recommend migrating to integrated DEX mode. Check our docs on that below:

https://docs.netbird.io/selfhosted/migration/external-to-embedded-idp

Sending client secret will be deprecated and direct google idp will be marked as not recommended anymore.

[Donemmanuelo]

what is the reason

[mlsmaycon]

Google IdP doesn't provide a good support for PKCE auth flow which doesn't require the secret token.

The migration will give you all you need and should be faster in terms of user email/Name cache.

[Donemmanuelo]

okay i understand that netbird client is meant to be a public client, and as a result no client secret is required, but google on it own need client secret, for flow netbird uses like deviceauthorisationflow(that is what am using) and pkce browser login to work