LNURL-auth

LNURL-auth is the LNURL subprotocol (LUD-04) that turns a Lightning wallet into a password-free login credential. Instead of a username and password, the user proves identity by signing a server-issued challenge with a key the wallet derives deterministically from its seed, so the service never stores a secret that can be leaked, phished, or reused. It is one of the quiet triumphs of the Lightning ecosystem: authentication that inherits Bitcoin's key discipline rather than the web's password habits.

How the flow works

The service generates a random 32-byte challenge called k1 and encodes it into a login QR code or link. The wallet decodes it, shows the user the requesting domain and the action (login, register, link, or auth), then signs k1 with a linkingPrivKey using secp256k1 — the same curve that secures Bitcoin transactions — and submits the signature together with the corresponding public linkingKey. The service verifies the signature against the challenge it issued, and on success the supplied public key becomes the user's stable identifier for that site. Because each k1 is single-use — services cache issued values and reject any reuse — a captured login exchange is worthless to an attacker, which is the same nonce-based defense against a replay attack that sound protocols use everywhere.

From the service side, the appeal is operational as much as ideological. Implementing LNURL-auth means storing public keys instead of password hashes, which converts the worst-case breach from a credential dump sold on a forum to a list of keys that were already public in spirit. There is no password-reset flow to support, no email infrastructure to run for recovery, and no incentive to collect an address just in case — a natural fit for services that want to know as little about their users as possible. Wallets implementing LUD-04 span custodial and self-hosted options, and the flow works identically from a phone scanning a QR or an extension clicking a link.

Why the linking key matters

The elegant part is domain separation. The wallet derives a distinct linking key per service from its master seed — for example via a BIP32 derivation path hashed against the domain name — so the same wallet presents a different, cryptographically unlinkable identity to every site. Two services cannot correlate their user lists by comparing keys; there is no global identifier to track. Compare that with "Sign in with" federated logins, where one platform observes every site you enter, or with email-based accounts, where a single breached database burns you everywhere. With LNURL-auth there is no shared password to phish, no hash database to breach, and no identity provider to deplatform you — the credential lives in the same seed phrase that already secures your sats, and rotating or abandoning an identity is as simple as never signing for it again.

Limits and place in the stack

Honest caveats: LNURL-auth authenticates a key, not a person, so account recovery reduces to seed backup — lose the seed and the account is gone with it. Adoption is concentrated in Bitcoin-native services rather than the broad web, and the UX depends on wallet support. It also authenticates you to a service; it is not anonymous by itself, since the service still sees your IP and activity. It shares the challenge-signing spirit of a NIP-07 browser signer in the Nostr world, and both point at the same future: identity as a keypair you hold, portable across services, revocable by no one.

D-Central documents LNURL-auth under the broader LNURL umbrella for Bitcoiners who want key-based, self-sovereign authentication. It extends the self-custody principle from money to identity: the same discipline that keeps your coins yours — guard the seed, verify the domain, sign only what you understand — now logs you in.