Open the single sign-on authorization leg in the user's browser

[yuri-zeta]

Problem

The app performs the login inside its own webview, so a provider that requires WebAuthn cannot be satisfied: on macOS the webview only offers passkeys when the bundle carries an associated-domains entitlement and the domain publishes a site-association file, and this bundle declares neither. When a provider requests a passkey — or enforces enrolment — the login stalls with no authenticator to offer.

Reproduced on macOS 26 against Authentik with a passwordless stage (device_classes: ["webauthn"]): the webview loads /application/o/authorize/, then /if/flow/default-authentication-flow/, then sits on /if/flow/passwordless/ with no browser prompt and no way forward.

RFC 8252 gives the same guidance from the other direction: a native app should use the user's browser for the authorization leg rather than an embedded user-agent. MA's own mobile apps already do this (ASWebAuthenticationSession / Chrome Custom Tabs), which is why they work against the same provider.

Change

• Intercept the navigation to the identity provider (on_navigation) and, instead of letting the webview run it:
  • ask the server for an authorization URL whose return_url is a loopback listener this process owns (auth/authorization_url already accepts arbitrary return URLs — the mobile apps pass a custom scheme),
  • open that URL in the system browser,
  • wait for the redirect back to the loopback listener, then hand the Music Assistant token to the webview as /?code=<token>, the same shape the server-rendered login page uses.
• Store the app handle in setup. It was only set by start_desktop_services, so it was empty during the first login and the handoff fell through to in-webview navigation.
• Treat the provider's /if/flow/ pages as handoff targets too, so a mid-flow navigation cannot strand the webview.

No new dependencies (reuses ureq, serde_json, tauri-plugin-opener, tauri-plugin-dialog), and no changes to capabilities or the launcher UI.

Behaviour notes

• The browser leg returns to a loopback address, which Music Assistant treats as an external redirect, so its consent step appears once before the token is handed over.
• If the server has no oidc provider, or the sign-in is cancelled or times out, the app says so in a dialog rather than failing silently.
• On Windows, WebView2 does surface platform authenticators, so this is mainly a macOS (and some Linux) concern — but the handoff is harmless there too.

Verification

macOS 26 against an Authentik provider that enforces a passkey:

• before: webview loaded the provider flow and stalled at the passwordless stage, no browser prompt;
• after: the browser opens, the passkey completes there, MA's consent step is confirmed, and the app returns signed in.

cargo check is clean and tauri build produces a working bundle. (The husky pre-commit hook was skipped when committing, since it requires yarn which was not installed on this machine.)