The many problems with implementing Single Sign-On | Hacker News Reader

The many problems with implementing Single Sign-On

stackoverflow.blog

50 pointsnalgeon25 comments

I do wish this wasn't a sponsored ad masquerading as an engineering blog until the last paragraph, but yes, these things are extremely challenging. What people miss is that the big cost isn't building or integrating these things, it's supporting them. I was the IAM features product manager for a mid-market B2B SaaS and had to jump on calls multiple times a week to help our Fortune 500 client base with planning our their deployment of directory integration (SCIM). You would think you could train support staff for the task, but with each IdP having its own zany behaviors and nuances (or just not following the protocols at all, cough Azure AD), you end up needing to pay someone who is extraordinarily technical to be an absolute authority in how these things work and are managed at both ends of the connection. I was backstopped by two other support engineers who could help with the day-to-day and escalated to me as needed. So multiple staff level engineers, all just to support two identity related features (SSO, SCIM) for one mid-market SaaS.

Everyone likes to gripe (including here in this thread!) about B2B charging for Enterprise features like SSO, but withhold your judgement until you've actually lived through supporting it. The burden of helping a company like Meta integrate their weird, bespoke, homegrown identity solution into your business app could literally cost your business tens of thousands of dollars per year (and no, that's not a made up example).

Indeed, people forget about the cost and pain of supporting these things. For full disclosure, I am a co-founder @BoxyHQ, an open source devtools startup providing free enterprise SSO (called SAML Jackson), directory sync (beta - feedback is welcome), audit logs and so on.

Pricing is tricky, and as you said, people complain a lot. Since this is because we all have different points of view, we will never agree. But there are some things that most of us should agree, like the fact that we need to raise the security standards. Then the question is what we can do as a community - besides trying to avoid being on the sso.tax list.

(I work at WorkOS.)

This comment pretty much exactly describes why we're building WorkOS. Developing enterprise features yourself in-house is super time consuming and ends up being a huge drag on product development. We essentially want to provide "Stripe for enterprise features" so developers don't need to do this repeated work.

It's a surprisingly complex problem. We've been working on it for over 3 years[0] and still have a ton more work to do. This is not something you can hack together in a few months or solve with an open source package. Thankfully we are really well funded[1] with a long runway and hundreds of customers.

It also doesn't stop with SSO and SCIM. You end up needing of other stuff including authorization, permissions, encryption, compliance, and audit logs (which incidentally we launched today[2]).

[0] https://news.ycombinator.com/item?id=22607402

[1] https://workos.com/blog/series-b

[2] https://workos.com/audit-logs

(As a total aside, I agree it's not very clear this blog post is sponsored content. Will see if we can get the StackOverflow editorial team to make it more clear. We just wanted to use our marketing budget to ship something genuinely useful. ;))

Is this me or is this is a rambling post that eventually brings you to a call to action for some product?

I could dissect some of the comments in the blog post (doesn't seem to even touch oAuth) but I don't feel it's worthwhile.

Yes - implementing SSO is not trivial. But it significantly reduces risks for businesses who generally have staff turnover and need to protect company data. If you are planning to do B2B it really is table stakes these days.

p.s. please don't consider adding yourself to https://sso.tax/. :(

Me too.

We are still struggling to get SAML integrations to production. The actual standard isn't that bad (its just XML and X509...), the hard part is getting the business to understand certain caveats. SSO is not a win-win situation. It is an exercise in trade-offs.

It took an entire meeting to get our stakeholders to understand the unfortunate implications of single sign out... Also, asking the question "do all your SSO apps operate in the same security context" was a great way to summon some additional dragons.

We ultimately wound up at something where SAML can initiate sessions in our application, but the user is forced to re-authenticate with the IdP every time (so we eliminated the first S). Additionally, once a session is initiated, there is no taking it back from an IdP perspective. The only way to revoke a session is from our software via an internal timeout or application-specific logout action.

So, really all we've done is implement same sign-on. Single sign-on is emerging as some sort of fantasy timeline where everyone still works in a secure physical office and can associate shared tokens to a time clock or badge system.

> It took an entire meeting to get our stakeholders to understand the unfortunate implications of single sign out...

What are the implications?

I thought the Single in SSO was for identity, not frequency of authentication.

Infant speak for all IdP's but Azure allows for configuring a sign out url to solve this issue - when the user signs out of their Azure AD account, the sign-out url is called so that the application can revoke the users session.

This post seems to suggest that a SaaS startup would consider creating their own SAML implementation. If a SaaS startup is considering creating a homebrew SAML implementation, they are doing it wrong.

When it comes to SSO, "buy" instead of "build", and focus on the core value proposition of the service with that saved time and resources.

Out of curiosity, which SSO service providers allow end-customer to self-configure the SAML integration? Essentially every service that I have seen the SAML integration is only configurable by the service provider and often there isn't even API that could be used to let SP expose the functionality.

This is actually something we’re working on at PropelAuth[0]. Our general philosophy is that most SP’s don’t want to deal SAML and would prefer to just have their users manage their own org membership - whether that’s via SAML, invitations, etc.

We haven’t built an API for it though, instead opting for a UI that walks the end-user through the steps of integrating with their IDP. That’s partially because every IDP is so different that we felt you really need a UI to show exactly what to do.

[0] https://www.propelauth.com

WorkOS provides this via the "Admin Portal." https://workos.com/admin-portal

It's essentially a hosted UI that allows end-customers to fully configure SSO/SCIM/etc.

Demo: https://demo.workos.com/

(I work at WorkOS. :))

Not necessarily, there are actually 3 options: Buy vs Build vs Use OSS :) > https://github.com/boxyhq/jackson

"Use OSS" is very close to if not the same as "Build".

To adopt an OSS approach for SSO, the startup still needs to dedicate resources to researching the OSS options, deploying the OSS, integrating it, and most importantly, operating it.

Once the startup gets into the weeds of integrating SSO functionality with customer's IdPs, in the limit, the cost of the effort will start to approach "Build".

As others have pointed out, this article is both a) a valid problem, especially for small products breaking into enterprise and b) and advertisement for a product (WorkOS)

What I would be interested to know is: What open source alternatives exist which tackle this problem and how battle-tested are they (esp. given than SSO differs between org to org)? With a product I built, I just paid the Okta tax and had Okta handle all the complexity of integrating with external systems while providing a single interface for me to interact with (which on the surface is the same thing WorkOS promises), but if I'm inclined to build this out myself, what are the alternatives?

I see a lot of devs, especially on HN, complain about http://sso.tax, but until you build a product for exterprise, you'll really not understand the time and effort this takes (and all of this takes away time and effort that could be spent building your product)

Curious to hear more about other alternatives to building it internally, lately I've heard a few people claiming that they built it in 1 - 2 days. Still don't know how.

There are good open source solutions that let you plug and play these enterprise features (I am biased here). But instead of thinking about the problems with implementing Single Sign-On, I think we should focus on a bigger problem: How can we make security accessible and simple for developers? I am not saying don't charge for SSO, I know it helps startups be sustainable, but here is where I truly believe that open source is one of the key answers.

https://github.com/boxyhq :)

Anyone here who knows how much of this can be handled by an intermediary like CloudFlare?

Setting it up with Google auth took me only 30 minutes or so for static pages (details at https://huijzer.xyz/posts/static-site-auth/), but I have no idea how good it would be for securing a service in production.

There are two pieces typically with SAAS apps (that may or may not be applicable to static pages): authorisation and authentication.

In most cases, I see B2B offerings supporting SAML + SCIM which helps cover the authentication (AuthN) and authorization (AuthZ) pieces of the puzzle. Or you use oAuth.

Most SAAS products also need to map users to what they can do within the app so they need the concept of roles, permissions, etc. It can get quite complex, quite quickly. Something you typically don't need with single user accounts.

> many developers will roll up their sleeves, read authentication and authorization specs

Good luck with that when your boss expects it to be done by tomorrow.

Two opinions I have about SSO: I dislike CAP and SSO without strong 2FA (totp,fido,vendor app) those two introduce ease of access/use without adequately compensating for lost security. Apple's PAT is also preemptively on my shit-list.

We just implemented SAML SSO and it wasn't that tough with cognito.

Way easier, I might mention, than using the other product this guy mentions, Nylas, which is... difficult.

> Tags: partnercontent

It’s an ad. Is that how StackOverflow makes money?

Okay on one hand, I feel dumb for saying this, but on the other hand I’ve literally built SSO integrations this way, so…

What about OAuth2? I had very little issue building auth integration with both Okta and Google using OAuth, and storing the non-secret stuff about the user in my DB.

Reply on news.ycombinator.com