19 ms·
Show HN: Clerk – all of user management as-a-service, not just authentication
- colinclerk 6y agoHi HN - We couldn't be more excited to launch Clerk and help developers solve all of user management. It's been quite a journey to reach this point, with over a year of iteration on the developer experience before we found something developers love. Using Clerk will enable you to spend more time on your application, and less time worrying about the ever-growing list of user management concerns. Our team is listening in this thread and we're happy to answer any questions.
- dubcanada 6y agoJust wonder price wise, if I signed up for the free and then switched over to paid it would be $249 for 5000 MAU. Compared to say Auth0, which would be $114 for 5000 MAU. The only difference is profile, and Auth0 mostly covers it by allowing you to easily store metadata. I am not sure I understand what makes Clark worth 2x Auth0?
- ukulele 6y agoJust wait until you find Userfront, which does the same thing for free until 10k users
- tylermenezes 6y agoSometimes you get what you pay for. Personally I would not want my data managed by a company that doesn't even have a team page or mailing address (let alone security details) and appears to be using a Bootstrap template for their website.
- deleted 6y ago[deleted]
- OliverGilan 6y agoJust looked it up. I don't know how I've never come across this. Reading the docs quickly it seems like this is cheaper and easier/more intuitive to set up than any other auth service. Will definitely be trying it with my next project, thank you.
- slig 6y agoI tried very recently to research all the "auth0 alternatives" and that project never came up.
- dubcanada 6y agoAnother question, I don't see any mention of security. You are in complete control of our users/profiles and their login credentials and there is zero mention of how secure that data is.
- philip1209 6y agoAgreed - 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.
- colinclerk 6y agoHi 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.
- itisit 6y agoSOC 2?
- colinclerk 6y agoNot yet. We plan to pursue SOC 2 as we build out Organizations, since it's a clear requirement in a B2B context.
- itisit 6y agoAnd B2C. You really ought to provide more transparency around your current security practices on your site. I do not see why someone should implicitly trust your service without any assurances, guarantees, descriptions, whitepapers, etc. Here's a good reference: https://trust.okta.com https://trust.okta.com
- kleiba 6y ago@colinclerk, the "Explore documentation" link on the front page is dead.
- colinclerk 6y agoThank you! Resolved.
- laurent92 6y agoSo is it the same as Login with Facebook or Google? Google/Facebook/Clerk manages the GDPR (do you? that is 300% added value for a business) and the app can focus on the data? Is your main added value that you are not Facebook/Google?
- bigiain 6y agoGDPR 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...
- Ash-k 6y agoIf you don't mind me asking, What data do you store that you think is PII?
- aembleton 6y ago- email address - name
- bigiain 6y agoQuite often user profile data as well. Job title and company in a bunch of projects. Sometimes profile pics. Social media accounts. Location or address details - sometimes just coarse location like "Sydney", sometimes exact delivery addresses - sometimes geolocation co-ordinates used for geofencing or smart defaulting (Apple's new coarse geo location is a good thing here, but I wouldn't want to be the test case in court about whether or not that's PII). Phone numbers (if needed, like for SMS alerts or shitty 2fa verification requirements I can;'t talk people out of). Where I cone from (.au) even an ip address is considered PII under our Privacy Act if it's linkable to another identifier - an ip address on it's own is not PII, but an ip address and an email address makes the ip address into PII as well as the email address. (It's unclear, but this likely includes storing a "last login date" in your email-containing database table that "could" be correlated to a login api call with an ip address in your log files, even if you are not actively doing that.)
- gravypod 6y agoSeems like an amazing product! One thing that would be amazing for you to tackle is support for devices, services, etc. Things that are not driven by a user and do not have a browser. I've worked at a few IoT companies and authentication is always a massive pain in my ass. SSO for web pages is annoying, authentication for 3rd party APIs or devices that need to sit in the middle of nowhere and don't have people to "login" on them is a whole other layer of pain. I'd love if you had a solution in that area.
- amzans 6y agoThanks for sharing! Will consider it for future projects. It’s nice to see that there’s an MFA option, and login notifications coming soon. I build this into my small projects too - even if unconventional - because I like to be warned about unusual activity on my accounts. Last thing you’d want is someone taking over a super user or staff account without anyone noticing. Just a small note: would be nice to have a page describing your security practices. Congrats on the launch!
- alex-wallish 6y agoHow close are you to adding billing to this? And do you have a public road map anywhere?
- ridaj 6y agoI'd suggest making it very clear in your docs whose data you're managing, and (assuming it's all the customer's and you don't lay claims to it) how would portability work. I wouldn't want to use this without a very clear understanding of what I'm locking my customer base into. Are you offering any security benefits? What security is there against malicious insider threat? (Eg can you / people at Clerk impersonate any of my customers on demand? Is there auditing/accountability for such activity? Is this something that sites with crappy roll-your-own user management would be advised to migrate towards, and if so why?
- brightball 6y agoIf I try Clerk for an application but decide I’m not happy with it, what is the process for moving my user management away from Clerk and into my own system?
- asimjalis 6y agoNice. If you could also add the ability to charge subscriptions from users and manage their subscription plans this would become a no-brainer. Also your pricing model could become very lucrative—you could charge a percentage of the revenue.
- colinclerk 6y agoDefinitely! We've found that developers want to apply subscriptions against either Users or Organizations, so first we're planning to build out Organization management first (create an org, invite members, setup SAML auth, etc). Subscription management will follow sometime after, and will probably look like a Stripe integration that automatically creates Stripe Customer objects for your Users and Organizations. Is this along the lines you're thinking?
- ketzo 6y agoBoth 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!
- asimjalis 6y agoIn 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.
- 6y ago
- mritchie712 6y agoDo you handle teams? Eg for a b2b SaaS?
- bsid 6y agoHey there, this is Braden, one of the founders - not yet. However, we're actively working on this :) We're probably going to start with basic RBAC/invitations before getting into planning for the full feature set -- which will include SSO/SAML/ more complex permissions (possibly ABAC), Audit Logs. Since we're tackling both the APIs and the customer-facing UIs, we think we'll be able to add a lot of value here
- sixhobbits 6y agoDefinitely see the need for this but its not that clear to me how it differs from eg FusionAuth which is positioned as an "Auth" solution but actually does everything(?) you call "user management" Not necessarily criticism, just my impression after a quick glance.
- faeyanpiraat 6y agoI'm even hesitant to trust Auth0 for this, why would I trust a new company?
- taytus 6y agoThis 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.
- kache_ 6y agoIt'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.
- bsid 6y agoHey, 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.
- 6y ago
- yuppiepuppie 6y agoAs someone who uses Django which has user management out of the box, why would I use a service like this?
- deleted 6y ago[deleted]
- TameAntelope 6y agoDjango does not have this feature-set out of the box, that's for sure.
- deleted 6y ago[deleted]
- theonething 6y agoLaravel does if you count installing their starter kit as out of the box.
- bredren 6y agoI’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/ https://www.pythonpodcast.com/saleor-ecommerce-episode-205/
- Rauchg 6y agoReally good stuff. The Next.js integration story is already really quite good[1] and the Clerk team has really good ideas on how to make it even better and more seamless. It's great to see a service focus on taking away all the pain related to user management, not just login. [1] https://frontend-docs.clerk.dev/react/quick-starts/next.js https://frontend-docs.clerk.dev/react/quick-starts/next.js
- kleiba 6y agoFor potential users in Europe, is there any documentation on GDPR-related questions somewhere?
- kleiba 6y agoDownvoted? Why? When user-related information is outsourced, the GDPR is absolutely relevant. Even the Google(!) screenshot on the landing page shows "Privacy and personalization" as the first item, that goes to show...
- bsid 6y agoBraden, 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.
- emj 6y agoThe question becomes; where is your company incorporated, where are your servers located. I was looking around on your website and it's very light on such details.
- bsid 6y agoWe definitely have a lot of work to do on content and more detailed information. Turns out high quality writing takes a lot of time and effort! Right now we're hosted on GCP in us-central. We will need to be more distributed as we start to tackle GDPR et al., making sure data is hosted in the correct location.
- alkonaut 6y agoDoes that matter really? For GDPR it's he users' location, no?
- buzer 6y ago
- tootie 6y agoThis is cool and all, but it's definitely not a new vertical. There are dozens of CIAM vendors up and down the value chain who do more than authentication.
- zorbash 6y agoIs the User schema[1] extensible? Can I add custom attributes or metadata to my users? [1] https://frontend-docs.clerk.dev/object-reference/user https://frontend-docs.clerk.dev/object-reference/user
- bsid 6y agoHey, Braden, one of the founders, very soon. This one is definitely low hanging fruit, and I actually want it as well for a side project I'm helping a friend with :)
- grinich 6y agoI'm the founder of WorkOS (https://news.ycombinator.com/item?id=22607402 https://news.ycombinator.com/item?id=22607402) which is sort of close to this so wanted to share a thought or two. WorkOS has taken the alternative design of ONLY doing authentication and explicitly not user management. This is a subtle but I think super important distinction so figured it could be useful to share why in this thread, especially for developers looking at auth solutions and thinking about their app's architecture. Essentially in the market right now there are a bunch of user-management-as-a-service solutions (Auth0, FusionAuth, now Clerk) and all of them have a similar design. They provide hosted auth UIs and they "run" your user database. This gives them control of the identity layer of your app, and they are the "source of truth" for users. This has some benefits (e.g. centralized admin) but in talking with developers, we actually found there are huge drawbacks which are not initially obvious. The user database sort of the data holy grail. It's arguably the most important and sensitive data your app has. From a UX perspective, the sign-in UI is the "front door" experience. It's the one feature that literally every user touches. In OP's post, they write: "Best of all, the components will automatically update as our team optimizes their design, develops new features, and adds support for the latest in account security." We found this was the LAST thing developers want. There are plenty of open source sign-in components (Tailwind, etc) but with Auth0/Clerk/etc. you never get full control over the UI. It's run by a 3rd party which may introduce random new features at any time. It's giving up a huge amount of control, both UI/UX and strategic. Plus you're always in the "uncanny valley" of design, where your auth screens feel slightly different than the core app experience. IT admins have trained users to avoid these sites because they are typically phishing attacks. Not good. Even with all this, perhaps the biggest downside for developers is a longer-term issue: you get locked-in. If down the line you end up wanting to run authentication through an unsupported provider, too bad, you're stuck. This is how Auth0 gets you. Developers integrate early, all the users are in Auth0, and then it's too difficult or dangerous to migrate out later. You're held hostage. And this is when they raise prices like an authentication racket. ("You've sure got nice app here. Would be a shame if something happened to it...” etc.) Obviously biased as I've founded a company in this space, but I think we've solved a lot of these issues with WorkOS, allowing for maximum flexibility with powerful authentication APIs while ALSO enabling developers to fully control the user database. It's been a super hard thing to get right and I should really write a longer blog post in itself. But just a forewarning to app developers: be careful where you store your user data. PS: A misc secret for the HN crowd, we're actually launching 2-Factor Auth APIs tomorrow. ;) Zoom link here for the stream: https://lu.ma/workos-winter-release https://lu.ma/workos-winter-release
- colinmorelli 6y agoWhat's the story around extensibility? I feel like it starts to get murky when the boundaries of data ownership are unclear. What if I have some bespoke user-level data that doesn't make sense for your system to store, but is massively important to my business (this feels to be the case for most products I build). Can customers extend your UI components? Do they store that data with you? One of the nice parts about authentication only is that it's relatively well-defined and not a place where customers frequently have variable needs (outside of just data sources to auth against). Cool idea either way though, and I like seeing more innovation in the space.
- colinclerk 6y agoHi Colin! On your backend, Clerk gives you a stable User ID for each user. You're free to use it as a foreign key in your database as you normally would. (clerk.dev runs on clerk, and that's how we do it internally) We only have a Node SDK so far - here's a guide on retrieving the User ID from your backend: https://backend-docs.clerk.dev/quick-starts/next.js-api-routes#3-create-an-api-route https://backend-docs.clerk.dev/quick-starts/next.js-api-rout... Soon we will launch a way to add custom attributes to the user object, as well as management of those attributes in the UI if desired. Things can get a bit murkier there, but those features will always only be opt-in.
- colinmorelli 6y agoThanks 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!
- colinclerk 6y ago
- nautilus12 6y agoI'm waiting for SaaSaaS. SaaS as a service.
- purplerabbit 6y agoI would unironically buy this... probably 20% of my job is wrangling SaaS boilerplate. Am I alone on this? Let's be honest, how much of the SaaS code you write could be applicable in any SaaS application?
- grinich 6y agoWhat's your job?
- purplerabbit 6y agosoftware engineer
- grinich 6y agoYeah :P But what are you building? Do you work at an agency building lots of new products? Or building internal apps? Seems most companies don't need new boilerplate as everyone is just adding code to the existing product.
- jokethrowaway 6y agoSaasify, but they want 20% of your business I don't think this model works, as small indie devs trying to do SaaS won't pay well enough and drown you in support and anything more than a mid company trying to do SaaS will reimplement their own (badly but good enough) in a month. Saasify with a few millions funding and a hundreds of sales could do ok, but investors are throwing money on other things these days.
- RyanGoosling 6y agoI like to use .NET Core Identity services with Azure AD B2C. Very easy to setup and generic interfaces are already defined for password reset, etc. https://docs.microsoft.com/en-us/aspnet/core/security/authentication/identity?view=aspnetcore-5.0&tabs=visual-studio https://docs.microsoft.com/en-us/aspnet/core/security/authen...
- jzer0cool 6y agoIs this hosted on your own backend? Should the time or need arise if available, what are some recommended steps to migrate off if needed?
- spankalee 6y agoAre the components only available for React?
- colinclerk 6y agoThanks 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?
- aembleton 6y agoSvelte
- catchmeifyoucan 6y agoThis is very promising! Going down this path now. 2 questions: 1. What happens if you go down? Then our users can’t auth in right? 2. I saw in one of the screenshots the ability to connect OAuth providers - will your service also store refresh tokens for these api services?
- rexreed 6y agoThe pricing model has me confused: 1) Pricing is free up to 5,000 MAU 2) But the next pricing grade starts at 1,000 MAU for $49/mo + $0.05/MAU additional so if you have 5,001 MAU you take a big leap from $0 to $249/mo Is there a reason for that huge bump? Why doesn't the first pay tier start at 5,000 MAU? And how is MAU even calculated? Like, aren't all users in the system active users? Or are you able to have a bunch of unactive users in the system as well not counted?
- kilburn 6y agoTypically MAU means "users that logged at some point during that billing month". That is, when you are billed based on MAU you don't pay for the number of users in your database, only for the ones that actually use your app/service/whatever.
- rexreed 6y agoTypically, 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.
- deleted 6y ago[deleted]
- colinclerk 6y agoThe copy was updated to say: > Our prices are based on your Monthly Active Users (MAUs) and not your entire userbase, so you only pay for logged in users who interact with your website during the course of the month. Does this help clarify? Sorry for the confusion.
- wasd 6y agomau usually means logs in once during the month, if you have 20% mau that's 25k registered users. $250 / mo to manage a site with 25k users doesn't seem that bad.
- 6y ago
- somid3 6y agolove it!
- deleted 6y ago[deleted]
- _rohan 6y agoThis is great. Do you have plans to provide any native mobile (iOS/android) support?
- colinclerk 6y agoYes - we're hiring now to help get this built! https://apply.workable.com/clerk-dev/ https://apply.workable.com/clerk-dev/
- polote 6y agoFew things I dont get: - Who is your customer type ? Individual developers ? IT of companies ? - What do you bring in addition to Google G Suite ? - Why is that important to have beautiful UI ? - Why would I use your service to power auth of my service, as it would probably take more time to integrate your apis, and configure your frontend to my branding than do it from scratch ?
- colinmorelli 6y agoNot OP, but: - Presumably, engineers building customer-facing applications - Google G Suite can be a fine SSO solution for internal apps, but isn't the thing you're going to use for your customers - I'm not sure how to answer this one. Surely it's quite obvious how a beautiful user experience is valuable? Your customers aren't comparing your experience against your competitors, they're comparing you to the best experience they have seen to date in any space. Companies who don't invest in their experience (and by extension, their visual design) will fall behind. - At a surface level this may appear true, but in practice people often significantly underestimate the time involved in building a high quality and secure authentication system. If all you do is throw an email address and password in a table, then sure. But you're going to have sign up, log in, forgot password workflows (and emails) at the very least. Then, if you're actually trying to protect something, you're going to have password complexity requirements, brute force protection, 2FA (authenticator, sms, etc), security notifications, browser fingerprinting, etc - to name a few. I'm still not sure how I feel on the outsourced authentication concept, but certainly not because building your own auth is free or cheap. Just because it's such a critical part of data that it might be worth eating the cost for (but I'm not sold necessarily).
- xwdv 6y agoWhat startup is moving so fast they don’t even have time to write their own user management features and instead outsource it to a third party SaaS in perpetuity?
- bluefirebrand 6y agoBasically all of them these days. Somewhere someone convinced us all that "Authentication/Authorization" are hard problems that we should leave to third parties.
- type_Ben_struct 6y agoLooks great and I can see a lot of value in this having been disappointed myself with how much is left to the developer with services like Auth0 and Okta. Could you expand some more on the team behind this? As this service would be a critical part of any application relying on it for authentication I’m keen to know about the size of the team supporting it. Do you offer an SLA and 24/7 support?
- blhack 6y agoOkay now add billing to this and rocket to a $1B+ valuation.
- ucarion 6y agoTwo questions: 1. Why use this over AWS Cognito? 2. Any intention to manage authorization as well?
- SahAssar 6y agoI'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%2Fclerk.dev https://securityheaders.com/?q=https%3A%2F%2Fdashboard.clerk.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 with jsdelivr).
- QUFB 6y agoIt's not an especially good look, although I see in the past few minutes HSTS has been enabled!
- SahAssar 6y agoIt'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.
- colinclerk 6y agoThank you for calling out the headers. We'll work to resolve right away. And agreed on the CDN JS. We'll move these assets to the customer's domain.
- qwantim1 6y agoIt’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.
- the_arun 6y agoHow do you guys compare your service with Auth0 OR Okta?
- coding123 6y agoI have a feeling you guys will do well. Just today I was scratching my head with passport js craziness.
- kulor 6y agoReally cool, love your positioning towards the frontend as frameworks like Django handle the static side fairly well. I can't see it yet but I'm expectant you'd have ancillary forgot password & user management (manual signup/migration, disable account) flows in the works? A "one more thing" to have me hooked would be user/team billing management .
- arnonejoe 6y agoDoes anyone know how long this service has been around? Only worry is that this service goes under in year and having then to migrate to cognito or okta.
- bsid 6y agoWe've been quietly building for awhile, and today is our first public announcement. We are well funded, and don't plan on going anywhere, especially in the next year. This product is something I've personally wanted for some time, so will self fund and bootstrap the thing if needed. I definitely understand the hesitation though, and hopefully we can build trust over time.
- 0xfacfac 6y agotbh I think the whole point being user management as a service won't last long. eventually Firebase, Auth0 or Okta will implement this and there won't be any competitive advantage anymore.
- jerrac 6y agoSo, 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 service? Or, why hasn't one, or two, options emerged that everyone uses and I would have heard of by now? User management, authentication, and authorization, are all problems that have been solved in many apps, and there are plenty of best practices. So, just like you shouldn't roll your own hashing algorithm, I'd think we'd want to do the same with this. It would make sense for one of the open source companies or organizations like Canonical, RedHat, Apache or Mozilla to have at least tried to do this. The closest I can think of to an attempt is Persona... Anyway, just been wondering about this for a while, and thought I'd take the opportunity to ask.
- SahAssar 6y agoI haven't tried it but https://www.keycloak.org/ https://www.keycloak.org/ (by redhat) seems close to what you describe.
- digaozao 6y agoI have been using it for a year. No problems so far, and found it to be really flexible
- TedDoesntTalk 6y agoKeycloak FTW. Been using it for 18 months now in production.
- afrodc_ 6y agoKeycloak is great and pretty extensible on a per basis need.
- mamcx 6y agoI 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?
- Diggsey 6y agoHave you considered offering an on-premise solution? Ideally a docker image you can easily stand up and point to a postgres DB. I can only imagine using this "for real" if I could actually store the users in a database I manage. The last thing I want is to introduce a new 3rd party single-point-of-failure.
- bsid 6y agoHey Diggsey, yes we have. We've deployed this way for one of our customers. We still need a better story on how to migrate from hosted -> on-prem/private clud, but we're working on it. Feel free to contact me: braden@clerk.dev
- TedDoesntTalk 6y agoI can’t think of a more dangerous way to tie your revenue to someone else’s product. And what if you want to drop this vendor?
- nichch 6y agoSorry, no more authentication until we can get you on a quick call to talk about your needs.
- bgdam 6y agoI am actually astounded by the number of people on here who think this is a great product. I mean as a product it might indeed be quite good, but it also comes with the huge risk of you funneling your users into a third party company, who can then hold that as a knife to your neck (intentionally or unintentionally). Sorry but the greatest user management experience in the world is not going to make me use this. Maybe, if there is some kind of mirroring back of all user data to some database I control, I might consider it. But even so, I don't think it's a great idea to give away all my user info to a third company. I'm sure it's covered as necessary for functionality,but what happens if tomorrow Clerk gets bought out by Facebook and they decide the database of my users is now theirs to target for advertising? Especially when the privacy policy a actually says they will collect and share personal information with their affiliates and subsidiaries. Nope, sorry not touching this with a 100foot pole. And I will go further and not use any company that uses this for their user management needs.
- o_____________o 6y agoI'll take another look when you start supporting Org features like adding clients with seats. I would love to have something simple to use for an admin product.
- qwerty456127 6y agoDoes it provide LDAP/Kerberos or something like that? I am looking for a roaming sign-in solution for Ubuntu machines.
- deleted 6y ago[deleted]
- stefanmichael 6y agohappy to see this on the front page, congrats colin and braden! I signed up for a dev account last month, definitely will be using this for projects in the future. - stefan
- bsid 6y agoHey stefan, great to hear! let's catch up soon
- benkoller 6y agoHave you guys considered a open-core business approach? Would dramatically increase trust, and my willingness to throw money at you :)
- deleted 6y ago[deleted]
- hmsimha 6y agoI can immediately see how this would be useful for prototyping (and growing) a product! But it might be helpful to include a FAQ answering (at least) the following questions: - Can user information be exported for clients who may want to build out their own solution later? If so, what does that story look like? - Can account management pages be customized/styled to match the clients' branding? - What parts, if any, of Clerk are open source? Do you have a github? - Do free tier users have a grace period to upgrade/migrate if they exceed 5000 MAU, or is user access cut off until they upgrade? - Where are you located, and are you targeting certain regions/countries for new hires? Also, the tier pricing is a bit opaque. The "professional" tier pricing appears to start at $49/month (for <= 1000 MAU) and scale to $4999 (for 100,000 MAU). The "enterprise" tier mentions a volume discount (which would suggest less than $0.05/MAU), but presumably the overall price increases? If that's not the case, why not allow clients to remain on the professional tier if they don't need features exclusive to the enterprise tier?
- znpy 6y agobut also: - Where are you located, and under what jurisdiction do you fall?
- germs12 6y agoI would imagine this would complicate contracts with clients who are not interested in a 3rd party knowing their entire population.
- aryamaan 6y agoCongrats on the launch! I have started using Keycloak for one of my side projects. I am unable to get my head around it and was pondering there should be a Keycloak as a service. Also, solving the trust part is one challenge which I hope you folks would handle.