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

It's the same as before, clerk.dev does not have it and dashboard.clerk.dev had HSTS when I checked first too. HSTS is sorta irrelevant for .dev though since all of .dev is on the preload list in major browsers. I'd be more worried about the third party JS without SRI. Especially since including third party JS is an active choice while not having headers is an inactive one.

It’s a great idea, but your company is going to be a serious target. You not only will have the ability to control authN, but you’ll own authR also if you’re managing users and groups. You’ll also own all the conference rooms, printers, servers, etc., since you’ll be hosting Active Directory for the Windows folk... at least that’s how I’d understand user management for auth.

There was the use case at one point that serving a version of a popular 3rd party JS framework from a CDN would result in the likelihood of that file being able to be served from the browser's cache, because there would be a decent chance the end user had visited some other site that used the same popular framework.

That no longer works, see https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca... and https://developers.google.com/web/updates/2020/10/http-cache...

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

I have been using it for a year. No problems so far, and found it to be really flexible

Keycloak is great and pretty extensible on a per basis need.

I have found confusing then support for multi-tenants and your own auth tables (ie: put the auth tables in the schema of each tenant?) across the board. Exist one project where I can do both?

keycloak is great, it's very flexible and fairly lightweight (all things considered).

it can get a bit complex, but to be fair the whole oauth/oauth2.0/openid/openid-connect/saml is quite messy in general.

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

I second ory, that's pretty much a solved problem in my book.

Fast self contained binaries, easy to interface with Kubernetes.

Adding some UI around them and managing them via api is nice enough.

The only incognita is whether they're going to handle scaling (I hope I'll have this problem one day).

Hydra is for OpenId though, I'd point to Kratos + Oathkeeper.

Thanks! Cofounder of SuperTokens here - please let us know if you have any feedback or questions. I can be reached at advait @ supertokens.io

I’ve always wondered why parse was never more popular as a backend for people hosting personal and small scale stuff?

Just wait until you find Userfront, which does the same thing for free until 10k users

Agreed - but I would also be interested in knowing if they hold cybersecurity breach insurance. That way, users could actually submit a claim for major issues.

Hi dubcanada,

Thanks for your questions! It's good feedback that there's no security documentation up yet. We have a lot more content coming live in the next few weeks - but let me try to hit some of the most important points:

* Session management is handled with secure, httpOnly cookies. We have you set a CNAME in production so we can set cookies in a first-party context (SameSite=Lax). * Cookies are scoped only to domains that require authentication data. If your backend is on api.example.com and you're running hosted Wordpress blog on blog.example.com, Wordpress won't receive your session cookies. * Passwords are bcrypted * All frontend-facing endpoints have CSRF protection enabled

Please let us know if there is anything specific we can help clarify. We've gotten into the nitty gritty so there's a lot to document, and it would be great to understand what areas to surface most prominently.

I forget what this effect is called. Every once in a while a new service comes along that tries to compete with Amazon and there is a huge cost of entrusting the new entrant.

Thank you! Resolved.

GDPR and CCPA are important issues for this sort of 3rd party PII management stuff.

I'd be _very_ hesitant to use this without some very strong guarantees that legal won't come breathing down my neck because I can't point them to a contractual guarantee that we will be complying with those (and similar rules from other jurisdictions).

I lose enough sleep worrying about PII that I store in databases I manage. Farming that responsibility out to a 3rd party does not fill me with joy, it raises instead lovecraftian levels of horror about what I'd tell a judge about how I ensured an EU citizen's rights to have their data expunged from my auth/userprofle system...

Thanks for the reply! I think your last point is what worries me the most. I feel like it makes sense to tackle custom attributes, because you own the user management pages. But, I also feel like you're almost never going to be able to support the kind of flexibility customers will need if those fields are anything more than simply metadata.

It's nothing about Clerk specifically, it's just a problem with these kinds of products. I just worry that as your customers grow and scale, they naturally need to leave your platform (or downgrade to an auth-only solution). I'll definitely be curious to see how the product grows, though!

Laravel does if you count installing their starter kit as out of the box.

I’ve recently customized django-allauth to perform all modern expected user flows and it is actually a lot of work.

Allauth itself is opinionated, and some things were built based on expectations that are not reflective of today’s web apps.

It can be done but the lift is much bigger than one might think.

I also think one of the most important parts of django is user/auth.

Seeing FastAPI and modern frontends continually advance, and now this user management service, I’d suggest that Django is getting unbundled.

The missing part to me seems to be a stand alone ORM and something to replace traditional view/templates so existing django devs could onboard easier. Maybe these already exist or are in development?

I really like Django, but I do feel like there has been too much emphasis on stability and not enough experimentation to integrate API and modern frontend work into core.

I think some of this has to do with how unstable django was in its earlier days. Sort of a ptsd from that.

However, what has been forgotten is that it also allowed the project to handle changing developer needs and take market share from Drupal and others.

The best example I have seen of this problem is in the ecommerce package, Solear.

If you listen to the project founders in the the 4/2019 Python podcast, “Building Scalable Ecommerxe Sites on Saleor” you can hear the use case of the project falling away as modern frontend is coming into focus. [1]

The challenge is that was two years ago.

I actually see this as a problem for Python even beyond Django.

[1] https://www.pythonpodcast.com/saleor-ecommerce-episode-205/

I used PassportJS on a project last year, and a) it was a total nightmare to get it working, with very poor documentation and b) it does almost nothing. It's basically the "now draw an owl" meme of auth.

I've been building a Next.js app with a Django backend using django-rest-framework and dj-rest-auth. dj-rest-auth[1] handles auth and registration out of the box and takes no time to get up and running.

[1] https://dj-rest-auth.readthedocs.io/

> 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.

Literally just launching this for our site today. A bunch of boring Django views, a couple React <> Node apps for crazy fontend stuff, and a PyData ~flask app for backend. Django gives accounts + login screens + JWT/CSRF APIs, and the JS/PyData stuff just pass around CSRF/JWTs as usual. Reverse proxy does extra stuff, but not essential for security.

I would love to see allauth extended with some sort of React toolkit so we could do SPA logins without refresh. That seems like a much smaller lift..

Both of these are definitely features I would really dig, particularly if I'm able to subscribe to whichever one I need.

If I'm building a photo-hosting app, it would be a bummer to pay for/build out a big "Organization Subscriptions" feature; if I'm building an enterprise-oriented chat application, I wouldn't want to spend many hours or dollars on individual "User Subscriptions".

But that said, I recognize splitting out those two features is more of a cherry on top; the main value here is just having them available to me in the first place. Either way, definitely keeping my eye on Clerk! Good luck folks!

In my case I don’t care about organizations. I am an individual dev who would love to use something like this to easily build apps that I could monetize. I am thinking of a web equivalent of the Apple iOS app store. Some place where you write an app and let the app store take care of billing and payments. I have published several iOS apps and zero web apps mostly because there is no frictionless way of monetizing web apps. Feel free to send me email if you want to talk more about the use cases.

It's much more lucrative for authentication/authorization/user management SaaS companies to build trust with their customers than to exploit that trust.

Furthermore, with the economies of scale, there can be more investment done on security & protection of users by a common element. Think of it as a collection of companies pooling their resources on a single engineering team which is responsible for building a rock solid authentication system with many useful features. This helps little guys build on top of something which has the same efficacy as auth services that large companies can afford to build.

At the end of the day, it's a trade off.

Hey, Braden one of the founders. It's a good question, and a question that gets asked a lot. Out of curiosity would you trust a more established company like Auth0 or Firebase? We hope to gain developers trust over time, and we want to build a tool that makes it dramatically easier to build out session management, and a lot of these user flows.

A similar question that was asked only a few (10?) years ago, was "why would I trust a third party with my credit card data?" And now it's something that people don't think twice about, because of all the regulatory challenges around storing credit cards, and how bad a breach is.

We see auth, and more generically, basic user data, as a corollary to that. With User Data regulations popping up in different countries (GDPR/CCPA), in the next 5-10yrs, we think it will become pretty common place to use a service to offload some of these gnarly responsibilities.

I can answer with the opposite question. Why would you trust your homemade solution instead of heavily invested experts? Auth0 (and Okta and a thousand others) do nothing but auth and customer management and do it at 1000X the scale as most enterprises. They do it way better than your IT team could possibly do it. And support every cutting edge feature and potential use case. You can also get them to absorb indemnity for damages in case of a breach rather than absorbing the cost yourself. From my POV, you'd be nuts to try to own your own passwords if you're securing anything remotely valuable.

Most of the auth platforms I've used allow ways for you to migrate users off of their platform. You'd want to make sure at minimum you have their email address, but worse case scenario you'd require all users do a password reset essentially when you switch to the new auth provider. That's a horrible experience--but it's still an option. Better options actually allow you to migrate the user over as they login. You'd need to keep the "old" auth service around for a while though until you close the door on migrating.

There's also an argument to be made that companies like this could (certainly not guaranteed) employ security experts and have better implementations (through libraries) as a result. Those implementations could (if updated appropriately), yield a more secure auth solution. In that regard, going with a third party, who has expertise, could be "better".

Also, unless you're going to host your database that stores user data on prem, you're likely trusting a cloud with it.

If I missed the point of your question I'm sorry. Did my best to answer. I have no relation to any of these services, other than I've used some at times throughout my career.

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 ongoing maintenance.

Would you build an app using a database managed by someone else? Isn't data a crucial asset? Some call it the new oil, I've heard. Yet lots of people choose to use an outsourced database provider. Auth is more user facing than a database, but if you can get the data out, what's the difference?

That said, you should pick your own comfort level. Other options include self hosting (there are commercial and OSS solutions which you can run on your own hardware).

You should also have a frank conversation with any providers about their security posture (sounds like the Clerk folks are going to add some docs to their site about this, which is great.)

Another consideration: you want the ability to export your users should you want to move services. People who aren't self hosting with FusionAuth can get a database export from us, for example, if they want to migrate.

I have limited dev cycles, and would prefer to work on my product rather than google "how long does password reset token need to be" and writing auth forms.

As long as clerk.dev are compliant, and you make sure of that, yep, you can delegate them data and keep yourself in compliance.

Yes, you (the "data controller") use them as a "data processor" and if they act compliant with the requirements of one, you're all well. Stuff like this is what the "data processor" definition is for.

Typically, that makes sense. Specifically, there's nothing on the website to indicate that is how they calculate MAU. The website is missing this critical bit of detail to inform would-be buyers.

For me to take a company seriously MFA must be in all their plans. MFA is not an enterprise hook for upsell, it is a fundamental requirement for any online service these days.

You shouldn't make your users choose between MAU supported and features.

Here's how I would do the price tiers, since you asked:

* STARTER - Free up to 5,000 MAU, features as listed.

* STARTER PLUS - Add a credit card and just pay $29 plus $0.05 for each additional MAU over the first 5,000. Same features as listed for STARTER.

In this approach, MAU 0 - 5,000 is free, and MAU 5,001 is $29.05. In the Starter plus tier, 6000 MAU is $29 + $50 = $79 and 10,000 MAU is $29 + $250 = $279

* For the PRO tier, the jump is pretty dramatic between $29 and $249 for the same # of users, so I suggest a 2x rather than a 8x premium. This means that you should price pro at $49 plus $0.02 for all users. This makes 5001 users $49 + $100 = $149

In this arrangement you don't even need to have a 5000 starter cliff for Pro. You can start with pro at even 500 users if you wanted the MFA features and the cost would be just $49 + $10 = $59.

Just my 2 cents.

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.

Cannot upvote this enough. Cognito is the absolute worst solution you could choose.

Braden, one of the founders, I gave you an upvote! GDPR is definitely at the top of our mind.

We would love to make it so developers don't need to think about, or make it easy to think about, GDPR and CCPA, and any future regulations that come up.

What's your job?

Hey Grinich! Yup, that's me :) Small world indeed.

Svelte