HN Explorer

Ask HN: Lightweight Authentication

31 points by scoresmoke ↗ HN
I want to let users log in to my proof-of-concept Web app. However, I don't want to maintain a fully-fledged authentication solution, managing logins, passwords, OAuth tokens, and their recovery.

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?

25 comments

[ 3.0 ms ] story [ 69.4 ms ] thread
blondin
send an expiring unique nonce token to their email address. when testing period is over you could implement another solution.
jonahbenton
An excellent women's soccer publication, Equalizer Soccer [1], which seems to use Memberful, has the authentication system I want EVERY non-critical publisher/app to use-

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.

1. https://equalizersoccer.com/

giaour
Popeyes.com does the same. Is really convenient, and I appreciate not having to trust a chicken chain with anything more sensitive than my email address.
mooreds
My employer (FusionAuth) has the same feature in our community edition and it's quite popular: https://fusionauth.io/docs/v1/tech/passwordless/magic-links

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

do_anh_tu
Just use phone number and send a OTP code. User will understand it right away, and they usually have a phone in their hand most of the time.
mkj
For a personal webapp accessed from a few devices I just keep a list of session IDs in the app's config file. The web framework generates the session id, it's derived from a cookie with no expiry.

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.

v3ss0n
Just use Django, it has all builtin
heresjohnny
I second this, but unless you want people to sign up with a username (not e-mail) you’ll have to do do some tinkering.
v3ss0n
It's very easy to support non email login too
threatofrain
On a similar subject, does anyone have recommendations for how to roll your own conventional auth stack without using 3rd-party providers?
mooreds
If I didn't want to use a third party auth provider (disclosure, I work for one, FusionAuth), I would use a battle tested open source library. Whatever is standard on your tech stack (devise for rails, spring auth for java, .NET core identity, etc).

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?

threatofrain
Just for personal learning, I wanted to see how fast things could be if I kept everything within the same datacenter.
mooreds
Ah, okay.

Why wouldn't a self hosted auth server (keycloak, FusionAuth, etc) or a library integrated into your app (I mentioned some above for certain languages) work?

mooreds
Full disclosure, I work for a fully-fledged authentication solution (FusionAuth) and if your PoC succeeds, my guess is you'll look to make a move to a similar solution. But I understand your desire to go quick and dirty.

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.

mamcx
Something I wish exist is a solution that truly use my own tables and support multi-tenant. So you only configure the connection string and some SQL templates and that is all.
kcartlidge
Like the opposite of a cloud database. An anti-RDS. The third party is just an orchestrator for your local auth storage. I'd be curious to see how that works.

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.