- SignalDesk2小时前
Original Summary
(Forewarning - this is mostly just me ranting 😄 ) I'm very much of the opinion that someone building a SaaS should not be building their own Auth. It's remarkably fiddly to get right; there are a lot of pieces that you need to think of, and - most importantly - it's not your core domain. You can easily spend weeks, if not months, getting it all working and still have missed out critical pieces. As such, for my own projects, I've been looking into cloud-hosted IAM systems of late. And I've come to the conclusion that they all suck in one way or another. By "suck", what I mean is some combination of at least: Missing features Broken features Important features gated behind payment plans For some real examples here: Many providers have gated MFA behind payment plans. Often this means that you can't even develop against it until you start paying them money, which is going to be off-putting for people with highly constrained budgets who are just starting. Clerk does unusually well here in that MFA is gated behind a paid plan for Prod instances, but is still fully usable for your Dev instance. So you can at least build against it before starting to pay for the functionality. A surprising number of providers offer TOTP but not Recovery codes. This ends up meaning that if you lose your authenticator app then the only way back into your account is to email support and wait. Even worse, Cognito allows you to create a user pool where MFA is mandatory, but doesn't support recovery codes. In this case, if the user loses their authenticator app then there is no recovery path. It's remarkably common for providers to just not offer APIs for querying what functionality is available. This then means that you need to build knowledge of that into your app, which in turn means that changing your IAM configuration also requires at least a redeploy of your service, if not actual code changes. For example, Clerk has no APIs that expose whether MFA is available, what the password policies are, or anything like that. So that means that the application using it needs to just know the config. So changing the config means changing the application using it. And I can go on. I've gone through a list of about 30 cloud-hosted IAM services, and every one of them fell short in one way or another. Typically, what I've found is that they have fantastic support for some of the more enterprise features - SCIM, Enterprise SSO, custom log sinks, external user databases, various compliance levels (HIPAA, ISO27001, SOC2, etc.), and so on. This is great for companies already working at that scale. But it seems that none of them are actually suitable for smaller projects, whilst still offering a usable solution. It's getting to the point where I'm considering just building my own IAM service that is specifically targeted towards this segment - that is, people building startups, side projects, etc. People who would be overjoyed to ha
- 情报分类:商业与市场研究
- 分类依据:内容涉及商业、投资或市场动态
- 信息来源:Reddit · SideProject
- 发布时间:2026/9/20 18:33:05
- 暂无回复