How I Built LoginWithHN
vadosware.io
vadosware.io
I wasn't sure about how well it would work when I first launched it, but now, about a year and a half later, I'm really happy with it.
The biggest advantages are: I'm not tied to an SSO provider, I don't have deal with password management/security/reset/etc., and I have a super simple UX (identical flows for signup and login.)
What did you use to implement yours?
I use the same approach to the above, where users authenticate with an email address. I don't store any client state on the server though which is nice for regulations like GDPR.
I have 'logged in' users without storing a single piece of data about them! No tracking nor performance stats on the site either.
Or it is implemented with longer lived cookies and you block everything that won't expire with your current session.
(or you don't mean that you are blocking cookies but instead that the site is requesting you allow “strictly necessary cookies”, in which case the site is being overly cautious, no regulation requires requesting consent for a strictly necessary stored value and a value tracking a login session fits into any reasonable definition of that)
The concern I'd have with “login via email” implemented this way is that it could be faf to support if your sending mail server gets unexpectedly added to a blacklist somewhere so the messages stop getting through to a bunch of your users. That said, for a personal project I'd guess the risk is low if you are hosting on a reasonably good provider, don't have competitors who'd DoS you by making your service send out login tokens to a pile of random addresses. And even if it does become a problem it won't be an earth-shattering one for a toy project. I may have to try it in a future plaything.
Developer convenience over user experience, is great, until you realise your users are crazy.
As a toy project, you probably wouldn't even know about it.
And if you did, sometimes sending some users off disappointed on such a matter is a small price to pay for being able to quickly get on with other things. Supporting people who block even session cookies is like supporting people who use IE or an ancient Android browser - ideally you'd like to support everyone but getting 100% there is too much work that it would consume too much effort that would be more useful elsewhere.
If the issue is blocking session level cookies, then there are many many more services that such users have trouble with. There are other methods (adding session tokens in all URLs and form submissions instead of, or as a fallback for, the cookie value) but that is work to do and maintain, and adds its own issues to the mix.
> Developer convenience over user experience,
I'm not sure it is a hit to user experience, at least not a significant one for the vast majority. The login is a bit more faf than normal as you need to wait for, read, and action an email, but once logged in all is normal and there is the benefit of not needing to manage another user account's credentials.
SMTP isn't something I feel should be trusted as the key for an SSO system for important credentials, but again: we are talking toy/experimental/personal/PoC projects here.
> is great, until you realise your users are crazy.
Well, yes. To be honest, fending off a few crazies would be a benefit most project large or small ;-)
If you can reliably avoid these two, you're golden.
Default "login by email", with optional "set up password" link for those who have problematic communications.
You do want to make sure you add enhanced security around changing an account's email address (make them log in again, for example). The analog is forcing people to re-enter their password when changing their password in a more typical username/password system.
> Provide[s] a unique code or phrase to put in their HN profile
The title speaks of being a "login with X" which made me expect something else than this manual step, like you could login to HN in a frame and somehow it queried your login status or so. Depending on the CORS headers, that could have been possible but then every site on the Internet can query the same, unless this person talked to HN owners. To me this is just the core interesting part of the story (but then I'm a security person who works with web security on a daily basis). The title isn't intentionally misleading, and it's still a "login with", just not how I was expecting it.
The title is a bit misleading, it doesn't actually "log you into" anything, it just verifies you're the owner of a specific HN account, at least according to https://news.ycombinator.com/item?id=30428282
You visit /login-with-hn, the server generates a code for your HN profile, you add it to your HN profile, and the server gives you a long-lasting sessionID (e.g. cookie).
Where it wouldn't count as "logging in" for me is if you have to first create an account with some credentials and then later link it to HN.
When someone implements "Login with Google", you get some sort of access to the Google account, the minimum being the email. But this service gives you nothing more than the public view of a HN profile. If someone told me I could "Login with HN", I'd expect things like the ability to post comments/submissions via that account when authenticated, but that's not what's happening here.
At that point, 3rd party login really is just "we'll contact their servers to authenticate you and then give you a session."
One example would be StackOverflow which lets you log in with Google/Github/Facebook but doesn't ask for any permissions on those websites.
Not every HN user? Oh wow. So, like, only 80% of us? I guess I assumed that the vast majority of us were not founders. How many of you are founders?
As an application developer, you get no access to HN because the 3rd party service doesn't have any access to HN to begin with. It's all just a clever workaround to validate "ownership" of a HN profile.
> this.ongoingPolls.set(hnUsername, displayToken);
Seems like debugging +10,000 interval timers could get hairy
So far we've had 700+ people log in (probably more after this post hit front page, I need to check), and so far it hasn't been a huge issue.
I gave loginwithhn a go, I'd recommend getting the user to type in the OTP. Checks their generation method is correct and makes sure they've managed to grab the secret before locking them out of future logins.
Keycloak is definitely more setup and a bit more clunky. I've never deployed Authentik though, I really need to kick the wheels on it and see how it works.
BTW in the simple auth/login space there is also:
- Keratin[0]
- GoTrue[1] (and Supabase's improved version[2])
- Authelia[3]
[0]: https://keratin.github.io/authn-server/#/
[1]: https://github.com/netlify/gotrue
- let's see what happens then to all the crypto skeptics around here. An about-face?