Consider a situation where you have a hyper-local web service. In my case, I was thinking of something like a household board game directory. Imagine that my friends and I could open the app when we want to choose a game to play, and the app could help make that process easier or more fun (in some way that isn't relevant to this article).
Probably it would be a mobile (or mobile-first) app. Typing in passwords would be tedious. Sending email magic links would require a mail server, which I don't want to host or pay for. So here's a different idea.
When attempting to log in, a dialog is displayed to a different user who is already logged in and currently active. This might provide a simple two-factor authentication key, and/or a QR code that they could show to the user who is trying to log in. They communicate this information to their friend, who uses it to log in to the service.
The core assumption is that the service is both social (involving multiple people) and hyper-local (based in a specific physical location), so we can rely on already validated users to be available to validate additional users.
Obviously at least one person needs to be able to log in without relying on existing users. Maybe users can optionally create a password, or admin users can connect to the server over SSH and get their authentication code directly from the server instead.
If the service is hosted on the open web, then creating new users should probably be invite-only (using a QR code link?), or else should require a short "room code" that changes occasionally. Once a user has an invite, probably an existing user should still be required to validate the new account, same as with logging in.
I guess that's it. Is it secure enough for informal, low-value services? That's hard for me to say, but it seems good enough to try out on a simple board game chooser app.
emptyhallway
2022-10-30