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.
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 :)
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.
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.
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.
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.
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.
Disclaimer: I work at Stytch.
Is their goal of “compromising your app” worth risking you noticing their (valuable, hard to create) zero-day and getting it fixed upstream?
> 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...
I'm using the Ory cloud solution but might dive into hosting it myself at least for local development against it.