What auth provider are you using in your stack, and would you choose it again?
Curious what the community is running for authentication/authorization in their apps (e.g. Auth0, Supabase Auth, Clerk, Firebase Auth, Cognito, etc.)
A few things I'd love to hear your take on:
What provider are you using and what's your primary stack? (e.g. Next.js + Clerk, Go + Auth0, etc.)
What's the one thing that surprised you , good or bad ?
Would you make the same call today? Especially curious if you've hit scaling pain.
For context: I'm building a B2C application with my own database layer, and currently in the process of evaluating which authentication provider best fits the architecture. Trying to understand how others are handling the auth <> database relationship and what influenced your final decision.
Great to hear your comments. Thanks!!
Replies
I’ve experimented with both Clerk and Supabase Auth in different projects. Both are great for getting something running quickly, especially when you don’t want to spend time building the whole auth flow yourself.
What started to matter more for me though was long-term control. Auth tends to sit at the center of business logic (permissions, roles, billing, multi-account setups, etc.), and once the product grows those edge cases start appearing everywhere. Because of that I ended up building my own auth layer in my current project. It’s a bit more work upfront, but it removes a lot of limitations later when you need custom logic.
That said, for many products the hosted providers are still a great choice if speed of development is the priority.
@pashupathi Hi, thanks for the feedback!
We’re using Clerk with a modern web stack, and overall it’s been a smooth experience.
The biggest surprise was how much auth affects product UX, not just security. Things like session handling, social login flow, and edge cases matter more than expected.
For a B2C app, I’d still seriously consider Clerk or Supabase Auth today. I’d mainly choose based on how much control you want over user data, roles, and how tightly you want auth connected to your database layer.
We are using Google OAuth in our Angular application with backend on Rails.
@lucreka They've asked for me for additional login options as well, but from what I've seen, more login options might get a little bit difficult to manage because the terms and conditions and the format of data might keep on changing from their authentication requests. Plus, instead of solving for each and every corner of it, we prefer having something which is more widely used and is globally stable. If someone doesn't sign up, if there's a lot of users who are not signing up and falling out of the login or signup page just because we have only Google and OTP signup, that is when it gets alarming.