Hacker News Reader

Comment by GauntletWizard | Hacker News Reader

Okta has always been a marketing organization first and a security organization second. Their support (and encouragement!) of bad protocols like SCIM and SAML are no surprise. Their target market are people who like easy solutions.

View on HN

Okta's primary use case is for enterprise orgs with dozens or hundreds of third party apps that need to be integrated. You use modern auth with the 90% of apps that support it. But there are almost always a couple of legacy apps that aren't going to add OAuth anytime soon if ever.

How do you propose your average enterprise should manage auth for these legacy systems without using SCIM?

As someone who has implemented SAML and SCIM, I agree with you about SAML.

However, I’m curious to learn why you think SCIM is a “bad” protocol, can you explain why you don’t like it?

How is SAML bad? Old and ugly perhaps, but are there specific security issues? Also SCIM; I don’t think it’s a great standard, but what’s the alternative?

SAML signs "XML Documents". It does not sign the specific bytes of a document, you have to perform a transform to get the "canonical" version of the document and that's what you perform cryptography on. This creates a large surface for different implementations to be incompatible, subtly, but more importantly it creates a surface area for the nastiest bugs in authentication - When the sender and receiver have different interpretations of the message.

This has lead to things like popular SAML parsers that do not even attempt to validate the signature. For examples of how this has gone badly wrong, see https://workos.com/blog/fun-with-saml-sso-vulnerabilities-an... .

Thanks, this was an interesting and informative read.

The short version of why SAML is bad is because it’s based on XML. This means that SAML is not only subject to the usual vulnerabilities that you’d expect, but also XML vulnerabilities!

A slightly longer explanation is that SAML is based on a garbage cryptographic signature standard called “XML-DSig” which, among other issues, allows for partial signatures and stores the signature inside the XML element that it signed.

Honestly, SAML is something of an info hazard. I don’t recommend learning more about it. But if you really want to, this blog post goes into more detail: https://dev.to/workos/fun-with-saml-sso-vulnerabilities-and-...

We (BoxyHQ) are an SSO and Directory Sync vendor like WorkOS and they are spot on with the details of the SAML vulnerabilities. We have guarded against these attacks so our customers don't have to but plenty of companies still roll out their own implementations, not all of them securely.

It's just riddled with vulnerabilities but most of them are now well known and mitigated.

OpenID was meant to be the successor but popularity wise SAML is still the champion with enterprises.

SCIM doesn't really have a successor afaik. Azure AD I think doesn't do password sync, I am not sure who twisted Okta's hands to get this implemented.

It's all the same thing with a different flavor

You have a signing authority and it liaisons access. Though it does go in the wrong direction a little bit with SAML

For what it’s worth…

The people who like easy solutions are the Fortune 500.

don't hate the provider hate the buyer

if someone tells me to sell them shit for 1m ARR i'm going to get squattin and shittin

I'd say that when the provider says "it's safe!" (and Okta does that: the words trust and secure are all over their front page), then the buyer may assume that it's true. Should the buyer get hacked because the provider leaked plain-text passwords, it is clearly the latter's fault.

If I sell you shit and you happily eat it, but then 3 months later you're like "dude, why did you make me eat shit?". Idk.

seems kinda like the responsibility of the person building the application and managing your users' data to do your due diligence on where the keys to the kingdom go

but... on second thought it's crazy that okta even provides this lmao. It's different when you're a SaaS provider with a position of being secure compared to being an indie merc contractor. Hell, if I was an indie merc, I'd straight up just not do it out of principle.

You can't blame the shit-seller for making you eat shit, but you can choose not to eat at restaurants that have shit on the menu. I choose not to work with Okta.

Reply on news.ycombinator.com