Ideally, I'd like to receive a unique user token and allow one to log in back if they decide to return. I don't need any user metadata.
OpenID requires quite an effort and a provider like Google or Okta. The most-matching concept was Mozilla Persona, but it was shut down in 2016.
What is the better way to implement this? Should I stick to the plain old login-password combination?
You didn't provide a ton of details (the programming language affects library options, for example) but I would go one of the following ways:
* login with a social provider like google, facebook or github. I don't know what your audience is, but hopefully you know which of these (or any other) would have the most uptake. This delegates the entire authentication process to a third party and allows the user to choose the level of security they want around their account without involving you at all.
* look for an OSS library in your language that offers magic token login. This is what you are describing when you talk about the token. Implement that. If you can find such a library, this will be a simpler solution.
> What is the better way to implement this? Should I stick to the plain old login-password combination?
I'm not your user and we don't have any idea what your userbase is. I'd ask them. Lots of tech folks want a username and password so they can use a password manager. Non-tech folks would probably prefer one of the two above options.
1. enter email address
2. email me a signin link
3. i click the link
4. i am in, on whatever device i am using
There is no password and no needed coordination with my password management.
It is glorious.
It is glorious from the user perspective, but there are actually some subtleties from the implementation perspective that caused us some grief.
First of all, you have email configuration and deliverability. The answer is to outsource it to a provider like Sendgrid, SES, or Mailgun.
Then, there's anti phishing email software which can expire one time tokens as it probes to prevent phishing attacks. More on how we built around that here: https://github.com/FusionAuth/fusionauth-issues/issues/629
Here is the token generation logic
https://github.com/nextauthjs/next-auth/blob/main/packages/n...
https://substack.com/sign-in?redirect=%2F
..but they have the option of a password sign in as well. It's really a good idea.
https://firebase.google.com/docs/auth
You get hosted + UI + OAuth
There are many others:
https://supabase.com/docs/guides/auth/overview
...
..
Many auth providers support magic links. I recommend https://userfront.com/dashboard/authentication
You should also be able to get a free tier at Auth0
You can go with either self-hosted or cloud. Cloud is free for up to 100 users.
If you have any questions along the way: https://www.hanko.io/community
There's a "/register" page that just has a mailto: link to email myself, with the session ID in the mailto email body parameter. Easy to copy-paste into the config file when setting up a new device.
This is probably less useful for external users (who want to log in extra devices themselves), but something similar might work.
At the least, though, it would need 'you' to be pretty good at securing your now-publicly-accessible database resource. Perhaps there is a middle ground where the auth provider specifies an 'interface' (eg via OpenAPI) and 'you' provide a set of endpoints to fulfil that spec; a protective shield over the database which remains locked down internally.
Inverting the flow; an interesting idea.
This is complicated enough and standardized enough that I can't think of a good reason to roll your own, other than for exploration/learning.
Can I ask why you are interested in rolling your own? Is it to minimize dependencies?
