Implement auth/login protocol about lnurl-node

[fiatjaf]

lnurl-auth is only one request, it doesn't have the first request to fetch params from the server then another request that provides the server with actionable data. Instead the lnurl itself already contains query string tag=login&k1=random-32byte-hex. Wallet will see that and call the URL directly with query string params tag=login, k1=..., key and sig.

On the server side, once you use the tag=login to route the request to the appropriate handler. Then you use k1, key and sig to verify the signature.

const secp256k1 = require("secp256k1")

let signatureOk = secp256k1.verify(k1, secp256k1.signatureImport(sig), key)
if (signatureOk) {
  activeSessions[k1] = key
}

That example above supposes you have a super naïve object with the current active sessions (could be session cookies or any other form of session) and then you're assigning a pubkey to one of them, meaning that that session is now identified with a public key.

In reality you would probably keep these sessions on Redis or somewhere else. And if the application requires it (commonly) then create a user in a database with the given public key.

---

At https://etleneum.com/ I use the following approach:

1. Once someone visits the site, they start listening to a Server-Sent Events (SSE) endpoint identified by a secret random string.
2. At server-side, each secret is associated with a k1. That k1 is used in the lnurl-auth QR code the user sees.
3. If at anytime the user scans the lnurl-auth QR code, the server backend knows what k1 corresponds to each secret and sends a message over the SSE connection to that specific secret saying: "you're logged!!!!!!" and stores the secret temporarily as a login token on Redis.
4. Once user gets the logged message it stores the secret on localStorage so next time it visits the site once it starts listening to the SSE using that same secret the server already knows it is logged and sends "you're logged already!!!!!!!!!!!!!! welcome back user !!!!!!!!!!!!!!!!!!!".

Please note my code still has some stupid bugs there.

[chill117]

Thank you for the additional information. What about logging out / de-authorizing a linkingKey?

[chill117]

I've implemented the lnurl-login flow in this module, but I don't see how it is useful with either the current CLI or API. For this subprotocol to be useful, a session should be persisted to some datastore (in the case of CLI) or the API should allow the developer to listen for new successful logins.

[fiatjaf]

I didn't really look at how the module is organized, but it will be useful if some existing service could import it and use it to verify lnurl-login attempts (just verify the signature, in fact). That would be very useful for developers as no one understand signatures and public keys and so on in the webapp world.