We actually have a huge initiative at Clerk with what we're calling "Elements" which gives a you "radix-like" way to build up the UIs, for significantly easier customization - especially when you're trying to go completely custom. The default modals will always be easier to use, and we're simultaneously working on getting better customization there.
Here's an example building a "Sign up" modal in the shadcn style.
It is an interesting start. OrgProfile is going to be what makes or breaks such an effort, IMO. Building a single Org Admin UX for auth data as well as app data is the key - I want pre-built UI for managing and inviting users, but then want to easily add to that UI to include other org-specific configurations and view the org's data. If you land in a place where that is easy to do, I'd definitely reconsider Clerk for future projects, as I really do like the idea of what Clerk can deliver.
For example, Okta has a notion of whether a user is "authorized" to use the app, so you can end up being directed to Okta, prompted to log in, and then shown an authorization error. Users will often phrase this as some odd form of "not permitted to log into the app".
Further, Okta admins control the claims the user presents to the app, and those claims can often have authz implications. A "role" or "group" claim is the most obvious one.
I've spent endless time going in circles with Okta administrators who can't clearly delineate these two, or who don't understand what an "app" (Okta's term for a relying party) is, etc.
You may be conflating Okta a bit here. SSO is one feature of Okta, which stands for Single Sign On. SSO is typically used to enable users to sign into their core work account and then that login is used for all applications where SSO is enabled for the organization. If Okta is conflating things on their end, that does not make SSO mean more than it should, just that some group of humans is misappropriating terms.
You and I can separate out SSO-the-feature from authz features, but it's all one product offering from Okta. A normal end-user is not making those distinctions.
> If Okta is conflating things on their end
Okta need not conflate anything; a layperson is going to see "Okta is our SSO system" → "Okta provides these things", and there you are.
But groups muddy the water even further. Your SSO system is making authz decisions. If someone (reasonably, and correctly) asks, "can I have permission to use $app?", … and that app assignment is then made in Okta, there you are.
Okta is far from the only such SSO to have such features, but it's also ridiculously widely used.
(I don't know that I like that Okta hands app assignment to administrators, and not users, but such is the case. But things like group or role claims — essentially whatever passes for a modern day directory — that's authz, more or less, since the groups directly dictate.)
Hey, (clerk founder) why do you think Clerk's pricing is predatory? Our goal is to continually lower prices and be as affordable as possible. Outside the free plan, it starts at $25 for the first 10k MAUs. Eventually we want auth to be as close to free as possible, while selling addt. services built on top of auth/users.
Also, the clerk service has layered integrations, powered by an http layer. We have customers using each part of the layer for varied integration types. That being said, the SDKs for the spa frameworks are the easiest to use.
Thank you for the question! It's very easy to rocket into $500/mo+ when you start needing your add-on features that I really think should be standard for any paid tier of something like "user management as a service." User impersonation, MFA, custom roles/permissions don't necessarily have scaling costs with them so charging more for these features seems predatory. But I trialed your product prior to these pricing changes so I don't have first-hand experience implementing them, maybe there is some justification for the added cost.
Do you still need to be in a paid tier in order to ban users? It's been a while since I tried your product out and I seem to remember that being the case in the early days.
Yeah coming up with our pricing model was and still is challenging. We're due for a revamp. As with most things in tech, all of these features require a ton of time to build / maintain / etc. so while the marginal cost isn't that high, the development time for all of them is very meaty and still ongoing.
If you were comparing something like build vs. buy where you had to build every feature clerk has from scratch, just paying for clerk would be soo much cheaper. But not every app needs every feature, and there's also a lot of open source options out there that make the build out a lot easier, so that comparison isn't completely fair.
But the main idea is that we wanted most apps to cost ~$25/mo - $100/mo, and, if you're building a B2B SaaS, you're going to have far fewer MAUs, and so we wanted the base cost to be higher at ~200/mo.
If you, or anyone reading this, ever feel like they're paying "too much" for Clerk - reach out to us and we'll work out a custom deal or even help you off-board to something else.
Banning users is still currently on the $25/mo tier which feels wrong, it should be in the free tier. We're due for a pricing revamp again quite frankly to make these pricing options more attractive. The tricky thing with the MAU costs is that a lot of folks seems to think they have a monster on their hands and forecast for like 1M MAUs or something, which is so far from reality.
It's tough to balance all of these competing priorities -- and if we don't have enough revenue, we can't keep building and investing in the platform for which we have pretty big ambitions. I will say that over a long period of time we want auth to be free and we want build applications to be 100x easier than they are today. I'm kind of getting ramble-y, but we also recognize that clerk's not for everyone and your use case might not make sense!
Good to know! Can take a look at the fact no error messages were surfaced to help identify the problem. If you want to hop on a call together and figure out the issue email me at - brayden [at] outerbase [dot] com - and I'm happy to hop on and get this working for you.
At the moment we only support hosted databases and nothing from the local machine but we are working on adding support for this really soon! It's been much requested.
Clerk is building developer tools for the next generation of applications. We're looking for engineers and builders who enjoy having a lot of ownership and autonomy and strive for DX perfection and pixel perfection in everything they do. Attention to detail is paramount.
Well funded and backed by a16z, s28 capital, south park commons, and many others.
Why is this different than the massive sports-merchandising part of a teams business, where they sell more stuff depending on whether they win or lose? I imagine they'd want to bet.. err i mean hedge to provide real value to their business.
(despite the snark, I'm also curious how the situation is different)
We're working on the UIs portion over at Clerk (https://www.clerk.dev), however, we're not going all in on permission-ing and just giving folks enough "ABAC" so that we can actually power the UIs. I hope in the future we integrate with more powerful tools, such as warrant, to make this all more seamless :)
At Clerk, (https://clerk.dev, auth SaaS) we did a ton of work to get magic links to play nice with multiple devices, it's certainly a pain, and there's tradeoffs.
The crux of it is, do you sign in the "originating" device (where the magic link was sent from), or the "consuming" device (where it was clicked).
Because it's veryyy common for people to be on a website on their computer, then click the link on their phone, but still want to be logged into their computer. We opted for the "originating" device. But this has security concerns.
(you also need to worry about multiple tabs on the same browser, but cookies make this easy to deal with)
But, what if an attacker just sends a link to loads of email addresses, and one of the receivers clicks on it by accident? Their account now has been taken-over.
So, this needs to be combined with the notion of "trusted devices", and of course, not breaking what the user expects. All in all, a TON of work to get some marginal gains in some sectors, mainly B2C. IMO, B2B should always have passwords as an option. 1Pass is too widely used to ignore.
It's $5/yr in eth for the actual registration fee. The problem is that the transaction fee gas to register and maintain that registration is steep. So it's fairly common to register your ens for multiple years to save on gas. Once L2's/rollups are more mature and under community control, I expect ens to migrate to one and cut those transaction fees down substantially.
reply