How I Built LoginWithHN(vadosware.io)
vadosware.io
How I Built LoginWithHN
https://vadosware.io/post/how-i-built-lwhn/
58 comments
It'd be prudent to have an option of a backup email address, in case the primary one on file dies or becomes unavailable.
This is only possible if you store client state, like the primary email address.
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.
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.
What's the point of having them log in in the first place then?
Spam prevention and rate-limiting
I do the exact same thing for all of my new applications. Magic Link Auth is 10x easier then trying to store passwords. The added benefit for the user is they don't have to remember any more passwords besides their email password. Which is already used as a source of truth.
I'm doing the same, but using Auth0 for the login-by-email. I don't think it'll really tie me to anything since it would be trivial to change to another service.
What did you use to implement yours?
What did you use to implement yours?
I got an SMTP gateway from AWS: https://aws.amazon.com/ses/
This is a great option for UX. Here's a fun old post from 2008 (from a former co-worker) on a similar topic: https://almaer.com/blog/its-just-my-email-password
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.
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.
A good percentage of our outbound emails end up in Spam folders, Promotion inboxes, or heavily delayed. It might be simple to implement send a login link via email and convenient for those when it works, but when it doesn't, it doesn't. So the best is to have traditional passwords and an optional "send me a login link". If they get one of those two working, then great. But you still have to deal with password management / security / reset / etc. Nothing is trouble free.
Give the majority of people have working email, how about the other way?
Default "login by email", with optional "set up password" link for those who have problematic communications.
Default "login by email", with optional "set up password" link for those who have problematic communications.
The two big issues with this approach is that emails can be significantly delayed sometimes, and/or can end up in the spam folder.
If you can reliably avoid these two, you're golden.
If you can reliably avoid these two, you're golden.
Nice. I see potential problems, but nothing that would stop me using the idea for a personal project until it grew into something else (at which point I move to something else, and if it never gets to that point I've lost nothing but gained time I'd have spent implementing something else).
FYI, in Firefox, hitting the back button does not take me back from your app.
My annoyance about this approach is that it forces me to open a cookie exception to your app, or to get a new magic link each time.
That shouldn't be an issue unless you block session level same-server cookies, which is a bit OTT.
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.
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.
As someone who lives in private browsing mode only, and stores no history ever... yeah. This is a service I wouldn't use.
Developer convenience over user experience, is great, until you realise your users are crazy.
Developer convenience over user experience, is great, until you realise your users are crazy.
> This is a service I wouldn't use.
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 ;-)
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 ;-)
Why would email instead of user/pass/oauth require you to change your cookie settings?
How it logs me in via HN without having to submit my HN password to a party other than HN (the one thing I was interested in, buried somewhere in the middle of the post) is this good old hack:
> Provide[s] a unique code or phrase to put in their HN profile
> Provide[s] a unique code or phrase to put in their HN profile
> How it logs me in via HN without having to submit my HN password to a party other than HN
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
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
Though you could still implement login this way.
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.
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.
Yes, you can "login" as in "confirm this is the HN user they say they are", but not "Login as the HN user" as there is no actual connection to HN besides a token in the profile.
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.
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.
Well, when I log in with Github/Google/Twitter, I don't necessarily need to confer any account access to the website and I almost never do, so I'm not sure that's the defining factor of 3rd party login.
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.
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.
Yeah, a simple yet effective technique. Had to join a Discord server and they're doing something similar for some other site.
It's also how domain ownership is verified before issuing security certificates. It's used in a lot of places.
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 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.
> Not every HN user is a YC founder
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?
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?
Has anyone built something like this (A service which checks the account description to verify ownership) for PlayStation Network? I know that psnprofiles have this kind of system in place, but I couldn't find a public project.
PlayStation Network already does OAuth2. Here is an example of a website making use of it → https://accounts.klei.com/login
It's a bit unclear what details you get as an application developer when using LoginWithHN. Is it just to verify that a user is also a user of HN? Or do I get the news.ycombinator.com token so I can build HN clients that are able to post comments as the user?
This is just a 3rd party service (not affiliated with HN) checking peoples HN profiles (which are public) for a unique string that the 3rd party service asks said user to set. It's a bit like how custom domains names are added to (for example) GSuite email.
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.
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
You're right, that would be way more efficient -- it actually wasn't a huge problem, so I never found the need to combine them.
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.
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.
Neat, interesting read :-)
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.
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.
Great suggestion! This is not the first time it's been suggested either, I'm going to look into it!
Just curious what’s the advantage of using Ory stack, which is more work that requires you to develop the front end, rather than with Keycloak or Authentik that you just customise the front end template?
The advantage of ORY was that it required this somewhat custom frontend (since it's not password based) -- I'm not sure how much easier that would have been with Keycloak (my guess is it would have been harder), and I haven't used Authentik before so I'm not sure.
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
[2]: https://github.com/supabase/gotrue
[3]: https://github.com/authelia/authelia
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
[2]: https://github.com/supabase/gotrue
[3]: https://github.com/authelia/authelia
Fun idea! Didn't work for me tho.
Can you elaborate on how it didn't work for you?
I put the phrase in my profile but it couldn't complete the validation in a couple of minutes. Probably same issue.
Exactly! I guess it was hugged to death by HN.
Could you also setup an HN cryptocurrency (or token) and grant units according to karma and account age please (or whatever other factors you deem important)?
- let's see what happens then to all the crypto skeptics around here. An about-face?
- let's see what happens then to all the crypto skeptics around here. An about-face?
Please don't toss flamebait into HN threads. It leads to repetitive, tedious flamewar, and you can make your substantive points without it.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
Considering what moons did to the quality of discussion on various crypto subreddits, I think it is fair to say that this is a really bad idea, no matter what side of the crypto debate you stand on. At least if you appreciate HN discussions.
What's a moons? I'm out of the loop, apparently
A crypto currency distributed by accumulating karma on r/cryptocurrency. Essentially it encourages shitposting and karmawhoring.
Yeah, we need NFTs of your login so we can sell those.
Add an ugly monkey on your profile information!
Woah woah woah. Too far. Every monkey is beautiful.
The one I see in the mirror every morning disagrees.
that already exists
https://badge.orangedao.xyz
https://badge.orangedao.xyz
I don't like the look of that, but I like the name hacksweet, hoinz or hackoinz as names. For the first, each unit is a 'sweet.'
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.)