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.

[1] https://samlshield.com/

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.

I just run them at the same time. As long as each instance is working in different parts of the codebase, there should be no problem. No worktrees needed!

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! Really big fan of the work you guys are doing over at Stytch as well! We actually got started by thinking of what "agent native auth" looks like as a first-principle and realized the problem space was more than that, and what we actually wanted to tackle was making it as easy and seamless as possible for teams to ship with the tools they want.

We've talked to several massive Fortune 100 companies that have hundreds of models/workflows that have been developed but are stuck in purgatory because they can't get approved for production because of IT, Compliance, and Security Teams blocking them (for good reason!).

This MCP Security Analyzer was a natural thing that we would've had to build out regardless as we felt like it was table stakes for our Confidential Compute stack and we wanted to open-source it for everyone.

Would love to get in touch with you and chat because I think that there's a lot of areas where we trade notes.

My email is munam@ninesuns.io or you can drop your email and I'll shoot you a note! Thanks!

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!

thanks for sharing! excited to help make the SAML ecosystem more secure. would love to hear any feedback people have!

So many use cases for this! Excited to see what people build.

Thanks for sharing! Would love to hear how others are thinking about this problem.

I mean, that's kinda why we're all here, so...

EDIT: Coincidentally, it just dawned on me that I'm very likely replying to an AI that knows how to use the HN API.

I don't think they are based on their previous activity. Seems a bit to sporadic and tempered.

> 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.

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!

If website haven't been able to make even consistent logins and forms for humans to use, what makes you think they will be able to make usable API's for agents to use?

I've tried making a Firefox extension that fills webforms using an LLM and the things website makers come up with the break their own forms for both humans and agents are just insane.

There are probably over a 1000 different ways to ask for someone's address that an agent (and/or human) would struggle to understand. Just to name an example.

I think agents will be able to get through them easily, but NOT because the websites makers are going to do a better job at being easier to use.

Interesting, what's are the heuristics for blocking? User agent? Something playwright does, metadata like resolution or actual behavior?

The user agent is pretty low hanging fruit, but these days even your most standard captchas / bot detection algorithms are looking at things like mouse movement patterns - a simple bot controlling a mouse might be coded to move the cursor from wherever it is to the destination in the shortest path possible; a human might try for the shortest path, but actually do something that only approximates the most direct path based on their dexterity, where the cursor began, the mouse they’re using, etc.

Tools in this space rely a lot on human use of a computer being much slower, less precise, and more variable than machine use of a computer.

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.