Live data from Hacker News

Show HN: Clerk – all of user management as-a-service, not just authentication

clerk.dev

211–220 of 234 posts

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#211

Earlier quoted context omitted.

Agreed, MFA is so important that a company should be willing to pay for it.

I'm not saying companies won't. But if you want me to believe your security is top notch then you need to show me you take it seriously. Not offering MFA on the free tier tells me you're more interested in making money than in security. There are plenty of other features that an enterprise will pay for.

Auth0, Microsoft also have MFA as a non-free thing. Probably because they have to pay for an SMS/equivalent.

It would be good to offer SMS MFA in the free tier, providing the dev plugs in valid Twilio credentials.

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#212
post #152

Earlier quoted context omitted.

Hey all - looks like there's a lot of confusion on the pricing model here. That's our fault, sorry! The free plan does not include 2-step verification, and that was the reason for the increase in the paid plan. We'd love some feedback on how you'd like to see the free plan constructed. What would be most helpful for getting you started with Clerk?

If you are going to offer MFA, it needs to be standard. How would you feel if seatbelts in cars or life jackets on boats were a paid feature? What if your bank charged extra for declining suspicious transactions? Not the type of behavior you'd expect to see from the company you're handing all your user account data over to.

> What if your bank charged extra for declining suspicious transactions?

They do. There is a pool of money they make that they take from gains made on your money before you get the remainder as interest. That is what pays for that.

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#213

Are the components only available for React?

Thanks for the question! Right now we only have an SDK for React, but under the hood that SDK is a thin wrapper over Vanilla JS. What other frameworks would you like to see prioritized?

Svelte

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#214

As someone who uses Django which has user management out of the box, why would I use a service like this?

"Batteries included" Django is a no brainer for a lot of use cases. True. But clerk.dev seems to be targeting teams that use (javascript) microframeworks. They are building something people want and the pricing seems to scale well up to 100K users. If you have millions of users, I'm sure their enterprise team will give better deals than $0.05 / MAUs.

> the pricing seems to scale well up to 100K users

I'm not sure I agree. This isn't really an infrastructure cost, it's a direct COGS (cost of goods sold) cost, and hits the service's margin. For a SaaS business charging $10-1000 per month per user it's fine.

For a retail business though I think this could be prohibitively expensive. Let's say you have a 10% conversion rate and $100 a year spend for customers, that's actually only $0.83 a month per active user. This is a 6% margin hit.

Sure, maybe in retail you often don't need non-customers to log in, but maybe you do. Or maybe your active users correlate much more strongly with your paying users, but maybe they don't. Content-led, email newsletter style business could struggle with this pricing.

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#216

I'm probably not the main audience for this, but if you mention security as a top-level feature it might be good to fix these: https://securityheaders.com/?q=https%3A%2F%2Fclerk.dev https://securityheaders.com/?q=https%3A%2F%2Fdashboard.clerk... For me it is also a red flag to include third party CDN JS (especially without SRI) on security critical applications (like the login for the dashboard and customer logins do…

> For me it is also a red flag to include third party CDN JS Why anyone would use third party js for anything other than dev work is beyond me. Are people really building websites that can serve html, images, and css, but not js?

I think that most 3rd party providers say "DON'T HOST THIS FILE LOCALLY AS IT WILL BREAK WHEN WE MAKE UPDATES".

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#217
post #138

So, first, congrats on launching your product. :) Personally, I don't have a need for it, and if I did, I'd be very reluctant to use a proprietary service, but I'm sure there are companies out there who will be happy to use you. Good luck! ------------ That said, maybe the HN community can answer something I've wondered about... Why isn't there an Open Source, standardized, self-hosted, version of this kind of servic…

"Why isn't there an Open Source, standardized, self-hosted, version of this kind of service? Or, why hasn't one, or two, options emerged that everyone uses and I would have heard of by now?"

Because it is a lot of hard, strict and continuous work. Specially if you want - and you kinda need to, if you want anyone to use you - to provide customization for: styling, different databases, languages (both programming and natural), login methods (SSO, email, etc), email delivery systems, user fields, etc.

So people building open source generally will just solve their own problem and might share that, not solve a problem space one up with all of these combination complexity mess. The most "standard" open source I know is Passport.js, but it only solves the problem of login methods.

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#218

Earlier quoted context omitted.

"Batteries included" Django is a no brainer for a lot of use cases. True. But clerk.dev seems to be targeting teams that use (javascript) microframeworks. They are building something people want and the pricing seems to scale well up to 100K users. If you have millions of users, I'm sure their enterprise team will give better deals than $0.05 / MAUs.

> the pricing seems to scale well up to 100K users I'm not sure I agree. This isn't really an infrastructure cost, it's a direct COGS (cost of goods sold) cost, and hits the service's margin. For a SaaS business charging $10-1000 per month per user it's fine. For a retail business though I think this could be prohibitively expensive. Let's say you have a 10% conversion rate and $100 a year spend for customers, that's…

You would have to have all of your users (converting and non-converting) still logging in / using the service monthly for this math to work out, as they charge by monthly active users.. I'm sure this happens somewhere, and that's probably not the most ideal place for Clerk.

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#219
post #33
post #11

Earlier quoted context omitted.

This is my question as well. It's an honest question and hopefully someone can educate me. Why would anyone trust a third party with what is the most important asset, their users? Thank you in advance.

Hiya, First off, full disclosure: I don't work for Clerk; I work for a competitor which offers overlapping functionality, FusionAuth: https://fusionauth.io I think a sibling comment laid it out well. It's a tradeoff. You are giving up some control over how your users are stored for significant acceleration of functionality. We've had customers say we saved them 1-2 person months of time in initial build, never mind o…

[deleted]

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#220
post #138

So, first, congrats on launching your product. :) Personally, I don't have a need for it, and if I did, I'd be very reluctant to use a proprietary service, but I'm sure there are companies out there who will be happy to use you. Good luck! ------------ That said, maybe the HN community can answer something I've wondered about... Why isn't there an Open Source, standardized, self-hosted, version of this kind of servic…

I haven't tried it but https://www.keycloak.org/ (by redhat) seems close to what you describe.

Very tangent question but someone could help as the discussion is about Keycloak.

In particular, I am trying to solve the problem of how I can share client secrets (so they can generate access token using it) with the respective clients.

I don't want to share them over email/ password protected doc.

I tried making one client for each realm and adding one user to it. When I login via user account using GUI, I am unable to see any info related to clients.

What am I doing wrong here?

What are the good practices around this?

Thanks kind folks

Post reply on HN