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.
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.
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
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.
> 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
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.
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.
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?
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.
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.
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.
I sidestepped a whole bunch of user/password management/verification complexity by restricting my toy app (https://pitchy.ninja) to "login via email" where you get sent a code anytime you need to log in.
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.)
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.
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.
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.
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 ;-)
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).
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.
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.
When the email is not received in the customer inbox, you have a bit of a loop where the customer has a valid email but is not receiving the communication.
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.
58 comments
[ 3.4 ms ] story [ 105 ms ] threadI 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.
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.
> 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.
- let's see what happens then to all the crypto skeptics around here. An about-face?
https://badge.orangedao.xyz
https://news.ycombinator.com/newsguidelines.html
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
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.
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.
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?