Go Auth Lib | Hacker News Reader

Go Auth Lib

github.com

100 pointsdebdut45 comments

I would like a magic link to email + long time bearer cookie. Extremely simple. Email is used for recovery anyway. Is there any deal-breaking downside to that? Is it worth using eg Google to prevent abuse of e.g. excessive free tier account creation or spammers?

Use case: SaaS for non-techies on desktop, international audience with payments for premium service.

I am a big fan of that. The only problem I can see is that often the device receiving the email is not the one performing the authentication (i.e. I am on my desktop and I open the email on my phone).

If instead of a link there is a code to enter IMO (or maybe both) this system is very good.

Or as an alternative to manually copied codes you can include a QR code.

Yes but QR relies on camera which often isn't available on desktop. A common use case would be sign in on desktop, check email on phone. The code needs to be brought back to the desktop.

Could you have the qr code being scanned from the phone and the act of accessing the url on the phone is what allows the desktop to login? What would be the downsides of this approach?

Good point. Thanks! Code is good but needs lower adaptive entropy (nobody wants to write a sha256 by hand).

My biggest struggle with projects right now is how to handle auth. Sure hashing a password and pairing it with a n email is easy in theory, but there are bad actors with zero days for any db/backend I’d want to use and they can practice all they want on my app as it sits on a server exposed to the world 24/7.

I’m going with trying out firebase auth for the express apps I’m building now, but this makes me even more inclined to check out go when I’m finished with this latest project.

I've also been in this space recently and settled on trying Ory which is a kind of headless auth solution. I'm using it in Phoenix/Elixir which lacks an SDK for Ory but it all seems fairly straight forward.

I'm using the Ory cloud solution but might dive into hosting it myself at least for local development against it.

Ory looks promising. Can you use the free tier for multiple projects as long as they are low volume?

Hosting Ory isn't difficult, FWIW.

Security is ultimately a question of cost to attackers.

Is their goal of “compromising your app” worth risking you noticing their (valuable, hard to create) zero-day and getting it fixed upstream?

I feel like this is ultra vires? It's a common sentiment now that just hashing passwords is terrible, but we did this at every startup I worked at previously and it was fine. Is it really an issue? For an early-stage startup, almost nobody sees the app anyways lol--we'd all be lucky if we were popular enough to hack

For my current startup, my cofounder, who is the CTO, insisted we use auth0, so we do, but it's a pain. It's such overhead. Sometimes it's buggy. There is a lot of stuff we have done and (are trying to do) that would have been so much faster to build if we had just done it my way.

I wonder if I am very naive or cavalier about the security risks.

I would recommend taking a look at Stytch. It is a startup that aims to have a simple, customizable way of building authentication.

Disclaimer: I work at Stytch.

Thanks lol

Proving the absence of a 0 day for whatever your solution you are using is always going to be difficult. But dwelling in thoughts like this is close to crossing the border to FUD territory. And who says there isn't a 0 day for Firebase auth?

We can put our faith in systems that have been hardened over the years and are easy and reliable to implement. And email + hashed/salted password belongs to them. And by that, I specifically mean using a library that takes over the hash/salting part for you. For me, not rolling your own crypto not only means not implementing your own hash algorithm, but also staying off-the-shelf with the code that calls said cryptographic functions.

I also like to stay conservative with regards to session cookies vs. JWTs. One has been around for more than 2 decades, is well understood, and has some really solid cross-browser security measures behind it (HttpOnly, Secure Cookie, etc.)

I personally like using the Django contrib auth library for this purpose.

May I ask a related question? Have you found a good way to do session auth in Django with httpOnly _without_ having to hit the server and see if you get a 403 back? Because it’s httpOnly I cannot know client side if I have a session cookie until I try and fail once.

Usually people experience this when they're using a React frontend that's served from a CDN, while the backend is served from a separate service.

If that's the case, the pattern you're describing is pretty normal and not an inherent cause for concern.

If you really want to workaround it, you can do this:

First, host your backend and your frontend from the same origin, so the initial window navigation includes the httpOnly cookie (make sure your cookie is set to SameSite=Lax, NOT SameSite=Strict). Then, before the CDN serves your static content, run some middleware to ensure the httpOnly cookie is valid, and add some kind of marker to the page body to indicate they're signed in (or redirect away if they're signed out).

The not-so-trivial part is running middleware in front of the CDN, but that's possible with things like Cloudflare Workers, and these days it's built-in to Next.js for most hosts.

For this approach you'll also want to make sure you can check cookie validity quickly at the edge, or else you'll be slowing down your CDN a lot.

Honestly, I just send a request and see if I get a 403/401 or not. With DRF you get an additional "auth credentials required" error JSON object back, so you can just evaluate that client side. Since I use fetch for my current project, I just need to check the response.

Disclosure: cofounder @ https://clerk.dev

Auth isn't "hard" per se, but it's still a big struggle because there's just so much to implement.

For example, one of the most common attacks today is "credential stuffing," which is simply the practice of taking leaked credentials and trying them on other websites.

Protection against this is arguably trivial: implement HaveIBeenPwned and a rate limiter, and create a mechanism to update the password when credentials leak.

But that's a lot of work, it can take a lot of tuning to get the rate limiter right, the UX/UI for updating passwords is time consuming, etc, etc.

And that's just one piece of authentication security – there are so many described in NIST 800-63B.

And then there's also the challenge of keeping up with user preferences - Sign in with Google, SAML, Touch ID, magic links, etc, etc. This seems to be fragmenting rather than consolidating.

Obviously biased, but all-in-all, I think you're better off sticking with a service than pulling it in-house, even if you stay with one of our competitors :)

Disclosure, I work for one of Colin's competitors, FusionAuth. :waves:

Well said. The other piece is that it's undifferentiated. I always say "no one ever fills out a login form and says 'wow, that was so beautiful'." It's always a door between where users are and where they want to be, inside your application, doing their job or scrolling cat pictures.

Perfect candidate for choosing a service, imo.

Disclosure: I don't work for FusionAuth or Clerk, or any of their direct competitors, but I figured I'd join the disclosure club.

I've been using Clerk for the past few weeks and it is an absolute breeze. Docs are easy to read and understand. They've prebuilt enough and the features they included are pretty useful (like organizations!). However, they annoy you with lots of emails. Pros and cons.

Disclosure: I work for FusionAuth.

> Sure hashing a password and pairing it with a n email is easy in theory,

That way lies frustration and wheels spinning, as you spend time on undifferentiated functionality that is critical.

So, do some evaluations of the options out there (including OSS libs, framework provided solutions and auth providers) and pick one. It's a nice architectural component similar to a message queue or database. Only in very rare circumstances would you write one of those, and auth should be the same.

> I’m going with trying out firebase auth for the express apps I’m building now,

Good on ya! Anything is better than rolling your own. When you want to migrate off Firebase, you can get at least get your password hashes: https://fusionauth.io/blog/2022/05/25/how-to-migrate-from-fi...

nowadays i use only email auth link. no password. simply you provide email address ,receive auth link, click on it and you are in. for additional security you can implement TOTC auth google auth or alternative apps and in case of lost access to email you can provide recovery questions like in the olden days. or phone number verification.

The problem with this approach is when you're not using the same device/environment to read email and log in, for example when you're on someone else's computer (say, in a public library).

being ONLINE and consuming an ONLINE service implies you can access your ONLINE email account

It looks like this uses JWT, which was disgust here a few days ago: https://news.ycombinator.com/item?id=33019960

I think you mean discussed, although looking at the tone of the thread you linked to you might not.

It looks fairly well thought out. I can imagine myself adopting it for internal sites (e.g., auth against corp okta)

Does anyone have any experience with it? It's been a while since I've really dove into authentication best practices, so I don't want to comment on implementation quality. The interface looks nice enough to use.

remark42 is used in production, this has been taken straight out of it. now remark42 is used in thousands of websites!

[1]: https://remark42.com

I was just thinking the same thing. Curious if anyone else is using it with Okta, Auth0, etc.

One trouble I have with OAuth2 is that so much assumes social media providers or UI-based flows.

I’ve done it, but don’t really grok it. Part of the problem is that I crib it from another project or let someone else handle that but and focus on the “business logic.”

I have a Go project now and feel like that’d be a good way to force me over the hump.

Apart from this and https://github.com/python-social-auth , which languages have such meta-libraries providing uniform interface to authentication through a lot of social platforms?

Passport for Node.js https://www.passportjs.org/features

Socialite of Laravel for PHP https://laravel.com/docs/9.x/socialite

Vert.x for Java https://vertx.io/docs/#authentication-and-authorization

https://github.com/omniauth/omniauth for rails/ruby apps.

Ueberauth for Elixir/Phoenix https://github.com/ueberauth/ueberauth

asp net core

https://learn.microsoft.com/en-us/aspnet/core/security/authe...

I stopped reading when I saw "JWT".

Shameless plug, but I built a thing[0] that lets you set up auth in 2(!) steps after you've signed up.

It's not free, but it's VERY easy to use/complete setup, supports regular auth (username/pw, email), and has support for a lot of providers (especially twitter with it's dreaded OAuth 1.0 setup), and it's probably the easiest to get started with.

Try it out for free, send me an email (see profile) and I'll get you set up or discounted.

[0]: https://waaard.com/for/login

This title is interesting, because "Auth" (Authoritarian) and "Lib" (Liberal/Libertarian) are both used to denote opposite ends of the vertical axis of the "political compass."

ok no politics

We actually stopped using "auth" on my team and adjacent teams because it is such an overloaded term. The main things we have to deal with are authentication versus authorization, and people use auth regularly for both. So we try to stop people from using it.

a12n vs. a11n?

authn vs. authz, actually.

I still don't love those.

In my crazy personal web framework I went with "enticate" and "orize", just hacking the "auth" off the front. Unambiguous, and easy to keep straight, but probably not euphonious enough to ever catch on.

I don't know anyone who uses "Auth" to refer to the right-wing of the political spectrum--where are you located?

They aren't referring to the left-right axis, but the up-down axis of the traditional two-axis political compass

Reply on news.ycombinator.com