[colinclerk]

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 :)

[encody]

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.

[mooreds]

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.