jelambs

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.

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!

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.

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!

Thank you for sharing!

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.

Thanks for sharing! We had a slightly different cost/benefit analysis for our use case with fairly straightforward APIs but know that might not be the same for everyone.

We recently built our own codegen solution to automatically create, maintain, and document our backend SDKs so that we didn’t have to compromise on either quality or maintenance burden. Also see part one of the series where we discuss how compiler theory inspired our solution: https://stytch.com/blog/what-does-compiler-theory-have-to-do...

hi! co-founder/cto here at Stytch, would love to help you get up and running with Stytch! If you have any feedback as well, would be awesome to hear it. If there are specific questions/use cases you're exploring, can share some customer stories that speak to those use cases. Feel free to shoot me a note, I'm julianna at stytch.com.

Hi! Disclaimer, I'm the co-founder/cto at Stytch[0]. We built Stytch because we went through the pain of building auth both in house and with incumbent players and wanted a better tool for developers building authentication. Stytch is flexible to enable you to build the experience that you want for your users but we do all the heavy lifting when it comes to both authentication and authorization.

We have support for both magic links and google oauth as well as many more options, one of the benefits of going with a provider is that with one integration you'll be able to get more auth products as your auth needs expand and get more complex (ie 2fa with authenticator apps etc). We also handle all of the fun edge cases when it comes to things like email deliverability and ensuring that your magic links end up in your users primary inbox and don't get blocked by spam filters etc.

I'd love to answer any questions you have and help get you up and running with auth so you can get back to focusing on your product!

[0] https://stytch.com/

Super excited for this launch! We'd love to hear any feedback you have.

Hi HN! I’m one of the founders of Stytch (https://stytch.com/?utm_source=social&utm_medium=hackernews&...). We provide developer APIs and SDKs that make it simple to embed passwordless authentication in your apps. Today, we support email magic links, SMS and WhatsApp passcodes, and one-click user invitations.

We’re working on adding more features like session management, WebAuthn, OAuth support, QR codes, and more in the coming months. Our docs and guides make it really simple to set up authentication for a new app or add additional features to an existing app.

Here’s more on why we’re building Stytch: https://stytch.com/blog/why-stytch/?utm_source=social&utm_me... Sign up today and try it out: https://stytch.com/?utm_source=social&utm_medium=hackernews&...

Would love any feedback and questions!

Stytch (https://www.stytch.com) | San Francisco & Remote (US only)| Full-time | Visa Transfer

We build user infrastructure that makes it easy to onboard, authenticate, and engage your users. Improve security and user experience with flexible, passwordless authentication solutions.

Open positions include:

* Software Engineers - Frontend / Backend / Platform

* Product Designer - Consumer Experience

* Product Manager - Consumer Experience

Learn more and apply: https://stytch.com/about

Tech Stack: AWS, Go, Node, Typescript, React

I also recently spoke on the Business Logic podcast about our founding story and how we're thinking about team growth (https://businesslogic.fm/e8-julianna-lamb-on-organization-de...).

I sold used golf balls, I was lucky to have a golf course just out the back door. You'd be surprised how many golf balls get abandoned just off the course, so I'd go for a walk after dinner when play slowed down and collect the abandoned balls. Then sell them depending on their quality, some of the valuable ones for upwards of a couple dollars.

Scalable in the sense that supply was consistent. To truly scale, if I were doing it today, I would've built a website providing reviews of different balls and manufactures, so your recommendation for an informational blog. But I think the key here is developing expertise in something by being boots on the ground before trying to build something bigger.

Agreed, computers are generally way better than humans at catching many style issues. We utilize linters extensively, those enforce many of our style guide rules. However, there are some, such as the example pictured in the article, that aren’t always detectable with a linter. In these cases, we use the style guide as the source of truth to reduce the amount of personal preference that comes into code reviews.

Author here, I think that’s a great approach. We surface our guidelines for every PR by including a link to them in the description template. This acts as a reminder for people to be thoughtful about their review. I think the fact that our guidelines were based on input from the most senior to the most junior engineers says a lot about how much we value everyone’s opinions and perspective, not just the loudest voices.

Author here, that’s a great question! We approach this by ensuring that there are always multiple people that can review a given codebase or service. In practice what this looks like is we have teams that own our different services. Rather than just assign a random person from that team if you’re making a PR for one of their services, we utilize what we call “open” slack channels, where any one can ask questions of the team. So you’ll go to the teams’s slack and ask for someone to review. We recommend @ mentioning the people who’ve most recently made significant changes to the code you’re working in as they’re most likely to be the best reviewers. But by sharing the responsibility across each team, that ensures there’s no piece of code that only one person across the whole engineering organization is qualified to review. For projects within a team, there will generally be one or two dedicated reviewers and we utilize stand ups to check in and make sure no one is overloaded with reviews. And since the whole team has familiarity with the project, it’s easy to swap out a reviewer if someone is overwhelmed or on vacation.