6 ms·

Okta has always been a marketing organization first and a security organization second. Their support (and encouragement!) of bad protocols like SCIM and SAML a

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.

lll-o-lll 4y ago
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?
- jf 4y ago
  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-footguns-1feo https://dev.to/workos/fun-with-saml-sso-vulnerabilities-and-...
  - deepakprab 4y ago
    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.
- kache_ 4y ago
  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
- GauntletWizard 4y ago
  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-and-footguns https://workos.com/blog/fun-with-saml-sso-vulnerabilities-an... .
  - lll-o-lll 4y ago
    Thanks, this was an interesting and informative read.
- deepakprab 4y ago
  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.
jollofricepeas 4y ago
For what it’s worth… The people who like easy solutions are the Fortune 500.
hnzix 4y ago
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?
jf 4y ago
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?
kache_ 4y ago
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
- tgv 4y ago
  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.
  - kache_ 4y ago
    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.
    - GauntletWizard 4y ago
      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.

lll-o-lll 4y ago

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?

jf 4y ago
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-footguns-1feo https://dev.to/workos/fun-with-saml-sso-vulnerabilities-and-...
- deepakprab 4y ago
  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.
kache_ 4y ago
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
GauntletWizard 4y ago
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-and-footguns https://workos.com/blog/fun-with-saml-sso-vulnerabilities-an... .
- lll-o-lll 4y ago
  Thanks, this was an interesting and informative read.
deepakprab 4y ago
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.

jollofricepeas 4y ago

For what it’s worth… The people who like easy solutions are the Fortune 500.

hnzix 4y ago

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?

jf 4y ago

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?

kache_ 4y ago

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

tgv 4y ago
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.
- kache_ 4y ago
  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.
  - GauntletWizard 4y ago
    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.