When you click Sign in in the desktop launcher, your default browser opens at loudplay.io/auth/.... You sign in there, the browser hands the session back to the launcher, and you're done. Some users find this surprising — older versions of the launcher had an inline sign-in form. This article explains why we changed it.
The short answer
The launcher uses the OAuth2 authorization code flow with PKCE (RFC 8252). It's the standard, secure way for native applications to handle sign-in.
In plain words: your password (or login code) is entered into the browser, on the official loudplay.io site, with the browser's address bar visible so you can verify the URL. The launcher itself never sees your credentials. After you sign in, the launcher receives a short-lived token via a localhost callback (http://127.0.0.1:{port}/callback) — this token is what authorises you for the rest of the session.
Why we did it
Three reasons:
- Security. Inline forms inside applications are easier to spoof. A malicious update could replace the form and steal credentials silently. With browser-based sign-in, you always see the real URL — you'd notice if it was wrong.
- Standard. Browser-based OAuth2 is what most modern apps use (Slack, Discord desktop, Spotify desktop, etc.). It's a known, audited pattern.
- Single sign-on. If you're already signed in to Loudplay in your browser, the launcher picks up that session — no second password entry needed.
What you'll see
- Click Sign in in the launcher.
- The browser opens (or focuses if it's already open) at
loudplay.io/auth/.... - You enter your email + 6-digit code, or email + password.
- The browser shows a brief "Returning to Loudplay launcher..." page.
- The launcher window comes back to focus, signed in.
If your browser blocks the launcher from opening it (some Linux setups, some corporate environments), you'll see an error in the launcher. Manually opening the URL in any browser, signing in, and copy-pasting back is supported as a fallback.
"Why does the URL contain 127.0.0.1?"
After sign-in, the browser redirects to http://127.0.0.1:{port}/callback?code=.... That's the launcher listening on a local port on your machine — the redirect hands the auth code from the browser into the launcher.
127.0.0.1 is your own machine; nothing leaves your computer when this redirect fires. If your browser warns about the connection being insecure (because it's plain HTTP), that warning is a quirk of how browsers treat localhost — it's safe in this context.
"Can I get back to the old inline form?"
No. The browser-based flow has replaced inline sign-in across all current launcher versions. If you're seeing the old form, you're on a very old launcher build — update via the launcher's auto-update or download a fresh installer from loudplay.io/download.
On Android
Android has the same flow conceptually — the app opens an in-app browser tab to sign in. You see the same loudplay.io/auth/... URL, you sign in, the app gets the session. This is standard Android behaviour and isn't a Loudplay-specific change.
What if the browser doesn't open
Rare, but if it happens:
- Check that you have a default browser set in your OS (System Settings → Default Apps → Web Browser).
- On Linux, install
xdg-utilsif it's missing. - On macOS, make sure the launcher has permission to open URLs (it shouldn't need any, but corporate-managed Macs sometimes restrict this).
If none of that helps, write to help@loudplay.io with your OS version and we'll dig in.