My hot take is that the SSO tax is totally legitimate because SSO is a clunky and complex feature to manage in a secure way. In fact many SSO implementations are actually not that secure because SAML is a dumpster fire when it comes to security vulnerabilities.
Most companies can get equivalent security and a better overall experience just using Google OAuth. The argument that you're having to pay for security features that should be available to everyone just doesn't compute for me if you offer Google/Microsoft OAuth, which most smaller companies are going to be using instead of Okta/etc to begin with.
If you really need SSO, it's probably because you're trying to manage massive amounts of user and do SCIM provisioning, etc. In which case, there probably will be some burden on the vendor to make sure that this all works smoothly or they'll pay a vendor (like us, I am biased as one of the Stytch founders).
We built an open source library, SAML Shield [1], to help companies secure their SAML implementations. And while hopefully this helps reduce the burden for teams maintaining in house SAML, the reality is that it definitely is a burden.
interesting, does it let you manage multiple claude code agents without having to spin up different git worktrees? we were discussing the other day how that's an annoying limitation of claude code compared to codex, and the friction in having to manage those different worktrees feels just not quite worth it.
this is super interesting! MCP is really exciting in terms of what it can unlock for agent use cases, but still the wild west in terms of security. I was on a panel discussion yesterday where this topic came up, basically how do you trust the use of AI tools when so much is still unknown. I think the the idea of using something open source and tool agnostic is appealing, the landscape is evolving so fast that horizontal solutions like this feel valuable. Although I wish clients, anthropic, cursor, etc would build more protections in too so that we didn't have to spend so much time thinking about this. but they've barely implemented remote mcp support so I think we have a ways to go.
Hi! I'm biased as one of the Stytch founders but wanted to share my POV in case it's helpful. As others mentioned, any of the open source options are not going to be low management overhead, but can be great in terms of cost and flexibility. I worked with Keycloak in a previous role and I think it's a really great option if you do go the open source route, just be prepared to spend time managing it.
> True multitenancy
Many of the paid options you mentioned (workos, clerk, etc same goes for auth0) aren't actually multitenant, they've tacked on a concept of organizations to a user first data model. This presents some limitations as a result of users as the first class entity versus organizations, for example, membership across multiple organizations with different auth requirements (ie I can log into my personal with sign in with email/google but to log into a company account I need 2fa or SSO), multiple SSO connections per organization or a single SSO connection across multiple organizations (both common in enterprises where there's lots of M&A).
Happy to go into more detail on any of this or answer any specific questions you have!
> Using apps like GitHub Co-pilot and Cursor to auto-complete code requires very little skill in hands-on coding.
this is a crazy take in the context of coding interviews. first, because it's quite obvious if someone is blindly copy and pasting from cursor, for example, and figuring out what to do is a significant portion of the battle, if you can get cursor to solve a complex problem, elegantly, and in one try, the likelihood that you're actually a good engineer is quite high.
if you're solving a tightly scoped and precise problem, like most coding interviews, the challenge largely lies in identifying the right solution and debugging when it's not right. if you're conducting an interview, you're also likely asking someone to walk through their solution, so it's obvious if they don't understand what they're doing.
cursor and copilot don't solve for that, they make it much easier to write code quickly, once you know what you're doing.
we're looking at signals from the network, device, and browser as well as patterns across requests to identify these agents. in some cases, like operator today, it's quite trivial to identify based on the user agent but that's quite easy to mask if they wanted to.
behavioral data like mouse movements, shortest path, etc is helpful but likely to result in less of a deterministic signal compared to device intelligence based on those signals of where and how the request is being made.
we'll have a more in depth blog post on what we're seeing with this next week too.
author of the post here, yeah this is a really good point. I think we're going to see more people investing in building OAuth compatible apps and more thorough APIs to support agent use cases. but of course, not every site is going to do so, so agents will in many cases just be doing screenscraping effectively. but I think overtime, users will prefer using applications that make it easier and more secure for agents to interact with them.
I was an early engineer at Plaid and I think it's an interesting parallel, financial data aggregators used to use more of a screenscraping model of integration but over the past 5+ years, it's moved almost fully to OAuth integrations. would expect the adoption curve here to be much steeper than that, banks are notoriously slow so would expect tech companies to move even more quickly towards OAuth and APIs for agents.
another dimension of this, is that it's quite easy to block ai agents screenscraping, we're able to identify with almost 100% accuracy open ai's operator, anthropic's computer use api, browswerbase, etc. so some sites might choose to block agents from screenscraping and require the API path.
all of this is still early too, so excited to see how things develop!
Have you checked out Stytch? I'm more than a little biased as the founder but would love to hear any feedback you have if you do. I thought your blog post covered a lot of really important points that are often forgotten when evaluating auth.
We support both a user changing their own email and with our embeddable admin portal, you get an out of the box flow where your customers' admins can update the email (and any auth setting) for other team members.
Most companies can get equivalent security and a better overall experience just using Google OAuth. The argument that you're having to pay for security features that should be available to everyone just doesn't compute for me if you offer Google/Microsoft OAuth, which most smaller companies are going to be using instead of Okta/etc to begin with.
If you really need SSO, it's probably because you're trying to manage massive amounts of user and do SCIM provisioning, etc. In which case, there probably will be some burden on the vendor to make sure that this all works smoothly or they'll pay a vendor (like us, I am biased as one of the Stytch founders).
We built an open source library, SAML Shield [1], to help companies secure their SAML implementations. And while hopefully this helps reduce the burden for teams maintaining in house SAML, the reality is that it definitely is a burden.
[1] https://samlshield.com/