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).
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.
Is authR another way to say authZ? I've never heard of authR and a quick google seems to mostly show a cloudflare project and stuff related to the term "author".
I think authN is Authentication and authR is authorisation. Two related but slightly different concepts. The third of the trio is Accounting which completes the AAA, the family of protocols that mediate access on the internet [0]
It seems to be the new way to say it. I've known both as AuthN and AuthZ but AuthR picked up for some reason or another.
In the same vein, it seems like a lot of people aren't too aware of the "identity" space so there's a whole lot of re-inventing the wheel with external sources not realizing something already exists.
> 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?
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.
Well, if the JS is to connect to an end-point on their server (eg. Google Analytics) if they remove/deprecate the old API the JS file won't work anymore as it might not be compatible with the new API, so the JS file would have to be updated.
Oh sure! I guess we're talking about different things. In your example, Google is providing you a service, and they're serving the file.
I was talking about using 3rd party file hosting services like cdnjs.com and unpkg.com
It's gotten so bizarre that highly popular libs (even Facebook's React!!! )will recommend you hotlink these third party sites rather than give you a zip file to download and host yourself.
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.
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 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.
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.
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?
Canonical Identity Provider (https://launchpad.net/canonical-identity-provider) behind Ubuntu SSO is free software, but the documentation is lacking (it's an openid provider with oauth support for application tokens; not sure if it's been moved to openid connect). To get proper users and groups, you'd needed to extract Launchpad Registry from Launchpad itself (https://launchpad.net/launchpad), though I think some "teams" functionality was added to Identity Provider itself.
In general, if more sites grew proper OpenID auth vs justa subset of providers, we'd see more people run their own OpenID servers to authenticate against external services.
Basically, for an open source/free software service to succeed in this area, it needs to allow both federated and SaaS model because that's how free software people are :) And federated is hard because nobody accepts pure OpenID anymore (and it's funny: you'll trust an email address but not a URL as a unique identifier). But it's probably how hard it was to get working that's the issue.
"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.
ever since facebook acquired, then liberated Parse [0], it kind of fulfills this role.
You can roll any subsystem of it and use off-the-shelf providers for other subsystems (we pay a service to host the server, but we run our own dashboard server to poke into it, others run their own database and use just the API server, etc), but I suppose it's easiest if you run the whole parse backend as a whole.
Really 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.
Thanks Guillermo :) means a lot coming from you! We're really excited about the direction the development space is moving, next.js, react and frontend components are going to make full fledged web apps MUCH easier to make
Hi 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.
Sometimes 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.
Just 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.
Another 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.
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.
As the others said - XSS. Stored XSS can still be a vulnerability with secure cookies, but locally stored tokens are a dramatically easier thing to take advantage of as an attacker, as they can just exfiltrate the token and hit your APIs with it.
For web browsers, cookie-based auth solves a ton of browser-specific problems that history has spent a long time building up answers for.
And 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.
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.
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.
sort of like "economic moat"...yeah I can definitely see why AWS is quickly becoming a monopoly. 10 years ago? I might have used Clerk, I guess I'm not seeing what the value proposition here is to me its:
Do I trust a new service or continue with one of the most trusted service from AWS?
Yeah, definitely. It's a phenomenal virtuous cycle for AWS.
I think that honestly, the biggest sell for a lot of newcomers is gonna be "you don't need to know AWS!" -- in my (very limited!) experience, if you want to do X with AWS, you're gonna need to learn how to do W, Y, Z, and maybe A and B with AWS too.
Another selling point is if you are not using AWS infrastructure at all. If you are trying to build a service that you do not want to utilize the tech giants AWS or Google, it’s a selling point.
it's a tough sell imho because AWS has a learning curve but I feel like most devs are okay with being enmeshed for building scalable and secure systems on top of it.
AWS moves so quickly I think it would be a disadvantage to rely on a smaller, unknown 3rd party that tries to replace itself as AWS.
If 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?
Seems 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.
Thanks 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.
I'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?
So 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?
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...
Quite 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.)
I 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?
What'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.
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)
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.
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!
It's not documented yet, but our frontend components leverage an API that was built with the expectation that some developers won't like our designs, or will need something custom we can't accommodate.
In those cases, using the API directly should offer the flexibility you need.
I think Django has by far the best story here, so much built in or activated with simple plugins. It took us an hour to add 2FA.
On the other hand, looking at node.js it's really a dumpster fire[1]. Even when using passport, you are still back to writing the code to compare passwords at which point so much can go wrong. So there's a lot of scope for hosted services. This of course compounds the problem because those service providers are GREAT at SEO and content marketing, so now a lot of Google hits on nodejs auth end up recommending Auth0 &friends.
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.
"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.
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.
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.
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..
I 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.
Nice. 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.
Definitely! 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?
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.
Have 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.
Hey 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
It's shiny and new, but the privacy policy stinks. It reminds me of Google's shady practices.
"8. Disclosure of Data
We may disclose personal information that we collect, or you provide:
...
Other cases. We may disclose your information also:
to our subsidiaries and affiliates;
to contractors, service providers, and other third parties we use to support our business;
for any other purpose disclosed by us when you provide the information;"
Who are these "subsidiaries" or "affiliate" companies? Data brokers?
From a company perspective it might be worth it to shave the 2-3 months to develop and perfect your own system. But from a user perspective, you are selling them out. Most people may not notice, but do you really want to risk the legal exposure or PR nightmare if their affiliate companies abuse this user data, or perhaps a subsidiary company leaves the data unencrypted in some db instance.
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.
Both of the services you mentioned have had major outages in the past. Maybe it’ll never happen again, but your customers don’t want to hear about why they can’t currently do business because some service they don’t even know about, in which you’re hosting their data, isn’t working.
As ever, there are trade offs and you take the good with the bad.
Outages occur all the time. What difference does it make where exactly they're originating from if the end result is the same, from the end user's POV? You give them the same message in either case: "we're experiencing a temporary outage and are working on a remediation." I suppose you'll also be compensated according to contract SLAs, and if the hypothetical becomes actual, you can tune your contract renewal based on your observed losses in revenue accordingly.
Best case scenario, there's healthy competition in the space, providing more alternatives and allowing you to end your contract with them if the service sucks. Worst case scenario I guess is that the company implodes taking all its data with it, affecting untold amounts of businesses. A GDPR-like regulation stipulating the ability to export that data (so, user databases) would go a long way towards mitigating prolonged outages in that worst case, and in the best case of the worst case, their competitors are able to import the exports. And/or tools that can spin up a $database instance in $cloud.
Have you seen the privacy policy for this service? Clearly not GDPR compatible. Simply using this means you cannot service the EU.
Also, if your issue is that owning your user passwords is difficult, then I'm sorry that's just the nature of the problem. It doesn't get any easier by offloading the problem to a third party. Bcrypting passwords is not rocket science anyway. MFA libraries exist for pretty much any server library you use.
Sure a company dedicated to doing user management will definitely do a better job than you, but only if your needs align with those of the majority of its users. The minute you want something custom,and trust me you will you're back to doing user management yourself. Only now you have a giant opaque blackbox to deal with.
Also, tomorrow if Google buys the company,I'll have 20 hours of notice to integrate my own user management before they shut it down. If Facebook buys it, they'll use my user data for targeting their advertising. Either way, I'm in deep trouble (If I care about my users, which I think most people will).
Even ignoring these, the simple fact is that by the very nature of the company, it is a much bigger target for people trying to break into and steal user information,than my little saas could ever be. I'd wager for most people using such services they'd be more likely to get hacked as collateral damage rather than being targeted.
I mean, if you're an auth expert, that's awesome; but I think it's the absolute height of engineer hubris to pretend that the efforts of any one individual, no matter how talented and experienced, are able to match an entire organization of people who do nothing but this one thing.
Now, trusting this particular third-party? Definitely a big question mark! It's on them to earn your trust. But I think to say that third parties in general can't be trusted with your users is to be a little ignorant of the modern web engineering landscape. We trust a lot of people with a lot of things, and not in an unreasonable manner.
Authentication is webdev 101. If you can't roll your own you're in the wrong industry.
I really can't think of any good reason to hand crucial control of a site over to any third party, much less user authentication where one breach will potentially cost you millions and land you in jail.
The whole business model seems to revolve around being a crutch for people not capable or competent of running their own services.
Building a form and hashing a password is webdev 101, but go look at the feature set offered by Auth0 or other CIAM platforms. Passwordless auth, MFA, compliance management, customer profiling, workflows, threat detection, analytics. And then think about how much they charge for doing this all for you out of the box versus hiring a dev team and running them forever to support it.
Well, if you look at how many sites break auth, or something in the login flow... This is clearly not the case for most companies. Auth is definitely simpler than most problems, but plenty of teams get it wrong.
> I really can't think of any good reason to hand crucial control of a site over to any third party, much less user authentication where one breach will potentially cost you millions and land you in jail.
Because Auth0 and other providers have security experts specializing in prevent hacking attempts and there is no way you can do a better job than them unless you make it your full time job.
“Not have any security issues whatsoever” is literally impossible. Passwordless auth is the security equivalent of putting all your eggs in one basket. If someone hacks a users email account, now they have access to your service too. Now I’m pissed that you didn’t let me enable 2fa to prevent that or have multiple secure passwords to isolate the hack to my email. You could have just shelled out the 10 cents it would have cost to have my account in auth0 and prevent all of this with 2fa and fraud detection.
You’ve gone off on a personal tangent about how I as a user can increase my security. The topic of discussion was you claimed passwordless security had no security issues and I pointed out possible security issues. An individual can mitigate them, but they still exist
> But you claimed that the email can be hacked, I used an email forwarding service provided by google or apple.
I'm not arguing than an intelligent user can't get rid of security issues. I'm saying a product that uses passwordless login still has security issues. Not every user is going to do that and theyre gonna blame you when they get hacked.
> Again, I would be more convinced of real world evidence and statistics rather than theorising.
You first. You made the initial claim that passwordless login has no security issues. Systems should be assumed insecure unless proven otherwise.
> I'm not arguing than an intelligent user can't get rid of security issues. I'm saying a product that uses passwordless login still has security issues.
Like what? you keep saying "still has security issues", but you don't give any real world examples. Just saying "still has security issues" is not a good argument.
> You first.
Lots of companies use this method in the real world, Slack, Medium, Freetrade, Substack, Monzo (a bank) and many more.
If a bank and a stock trading app is comfortable using this method, I am sure they are comfortable with the security of this method.
In addition, I already have given examples in this thread which you willingly choose to ignore.
Your turn, start with this:
> Forwarding email increases risk of being hacked. They only have to get one of the emails to get into my account.
Sure, because “do passwordless emails” is just a snap of the finger away, right?
The point is that doing auth properly is hard. Sending an email might be easy, but creating and managing the session in a secure fashion is hard, even if you’re “just doing passwordless email auth”.
This whole comment thread is about not outsourcing your user management stack to a third party and your intended suggestion is.... A different third party?
I don't think I understand exactly what your argument is.
Ok it’s not just me then. I felt like I was taking crazy pills when reading the replies, and the ones to the sibling comment thread where they pivoted to talking about personal security with magic links when this entire conversation has been about companies implementing user management solutions.
This is a very reductionist assessment of the thread and glosses over one important detail I said here:
> The choice is yours to reimplement this authentication system, but in terms of "a snap of the finger away", You can do that, That is all.
It doesn't matter if it's a 3rd party, it is still an option that exists "a snap of the finger away", which was my response to that comment, this type of system can be done in an hour, 3rd party or library.
But if you want to speed things up, then there's your solution.
That was the point, but go ahead and try and reduce and spin this to your own interpretation.
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.
> 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.
It's not even worth evaluating at the free tier without this. I asked in their slack and they said they intend to support this, which is promising (though sounds like it's not implemented yet)
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.
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.
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't speak for anyone else, but I would trust a service like this a lot more if i could easily export all my data. I would do so on a regular basis, basically as a backup.
The other concern is what happens if you shut down or decide to change your plan to be prohibitively expensive? (I'm not implying that's the case for you, but it's a consideration that has to be made). There have been vendors in the past that have abruptly shut down without warning, leaving their customers scrambling to build or find alternatives. In all honesty, I'd rather build an authentication system from the beginning than having to take my service down at a critical time.
This is actually a really interesting product though, and i would definitely consider it on future projects.
Thanks for the comment and consideration. Noted on exporting, glad to know that would help on the trust front. Definitely something we should prioritize. Gaining trust is hard, and something we hope to do over time. We of course don't want to shut down, and want to be a go-to for small projects, which would mean keeping pricing low. We think we'll be able to do that by up-charging on the B2B feature set.
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.
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.
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?
Typically 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.
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.
> 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.
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.
I and GP comment seem to take the opposite stance: MFA is so important that products like this shouldn't offer a plan that doesn't include it. Either include it in your free plan or don't offer a free plan; don't make security an upsell.
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.
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.
I feel the same: The upper tier pricing is a bit aggressive even if free 5000 MAUs is a good "hook" (more than sufficient for most upstarts).
I've been meaning to evaluate keycloak.org and userbase.com, two radically different open source user management layers. Especially, userbase which has a relatively more attractive pricing for their hosted option.
Besides, user management is something I'd like to rid if I can, and instead rely on anonymous / decoupled (passwordless?) identity layers like human-id.org and gazepass.com
Cloudflare's OPAQUE is another enticing (zero-password) tangent in all of this, but they warn folks to not build identity systems using it, yet.
mau 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.
Definitely 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.
What 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?
- 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 ?
- 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).
Downvoted? 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...
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.
The 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.
We 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.
Some buisnesses, but mostly government, can not put their data on cloud services of companies that operate under laws like the US Cloud Act and similar things.
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.
This 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.
Looks 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.
Really 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 .
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
Also colinclerk are you Colin Sidoti? If so I was a few years ahead of you at MIT and I think we totally we met a few times around when I was graduating. Small world! :D
Hey, 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 :)
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.
I'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.
Does 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.
We'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.
tbh 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.
happy 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.
Hey 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
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 with jsdelivr).