4 ms·
Hi, blog post author here. This article is from Feb 2023, so quite dated at the moment. I'll write an updated article for 2024 but as you've mentioned here, it
by hyperknot 2y ago
Hi, blog post author here. This article is from Feb 2023, so quite dated at the moment.
I'll write an updated article for 2024 but as you've mentioned here, it's almost impossible to follow this landscape. So many solutions appeared during this time.
My recommendation right now would be to either:
- Use a reliable framework with a well-tested built-in solution like Rails/Django
- Choose WorkOS / AuthKit (1)
Some more thoughts:
- Clerk didn't turn out to what I thought when writing this article. Their offering is very much targeting the JS ecosystem, especially Next/Remix, it's not an universal solution.
- It's difficult to recommend hosted solutions when you see how much pricing changes even during 1.5 years. Like you decide on a solution then next year the company raises prices and you are stuck with it forever.
(1) Note for AuthKit: It's an amazing solution but it's a joke that users cannot change their emails. How can it be a production-ready solution, if it doesn't allow any app to offer email change for their users?
- grinich 2y agoHey thanks for the shout-out. I work at WorkOS / AuthKit. tl;dr - we know this feature is missing and we are working on it Changing email address is of those simple sounding features that has a ton of complex edge-cases that are critically important to get right. The crux of it is how organization membership/invites and resource sharing typically works with unconfirmed email addresses in apps. What happens with the old email address? Can a different user claim it? Are you allowed to change your email address if your account comes from SAML/SCIM? If you get this behavior wrong, it will lead to inconsistencies that can even cause security vulnerabilities. Solving this for thousands of different types of apps of course makes the problem significantly more complex. It turns out different developers actually want slightly different behavior, so we need AuthKit to be customizable to accommodate this. More than anything, want to avoid changing these APIs after launching them (even in beta) so there isn't developer thrash. We are working to make sure the solution is as complete as possible and that's taking longer than I would hope. In the meantime we have some workarounds. e.g. popular apps like Cursor are built on AuthKit and work great. Anyone can send me an email if you want to chat about this. We're also hiring if you want to work on it. :) mg@workos.com
- mamcx 2y agoI wish a library exists (in rust or anything that is easy to embed) instead.
- jenius 2y agoClerk employee here - it's certainly the case that a lot of our users are JS ecosystem users, which is why those SDKs have received extra attention. That being said, I do want to note that we have greatly expanded the number of SDKs that we offer over the past year or so. I'm not sure which framework you were using when you tried it out, but we may have better support for it now! You can see all our supported SDKs if you scroll down in the docs: https://clerk.com/docs https://clerk.com/docs