May be I am in a minority here, but there are areas where SAML sort of shines
1. For OIDC/OAuth2 the request has to originate from Service provider, most Enterprise IDP's rely on SAML for Single Sign on cause of its ability to do IDP initiated flows
2. The security for SAML is baked into the payload itself, provides safety against MITM attacks, even though the HTTPS provides similar guarantees in theory, the reality is that your SSL offloading happens elsewhere, not on your application server
The OP provided a list of vulnerabilities discovered in SAML, IMO this kind of comparison if flawed if you do not present the same for OIDC/OAuth2.
At the end of the day, these are tools and effectiveness of a tool is a lot dependent on ones skillset to understand and use the tool.
> The security for SAML is baked into the payload itself, provides safety against MITM attacks, even though the HTTPS provides similar guarantees in theory, the reality is that your SSL offloading happens elsewhere, not on your application server
This is just as true for JWT. Actually its a lot more true for JWT as people usually implement this wrong in SAML.
Additionally, https doesn't really protect you here, as typically the user sees the token/saml document, and they are the main party you have to worry about being in the middle.
> this kind of comparison if flawed if you do not present the same for OIDC/OAuth2.
i'm doubtful there are any vulns in oidc/oauth2 that aren't present in saml. SAML vulns are typically a strict superset of oidc vulns.
sandeepkd · · focus · HN ↗
1. For OIDC/OAuth2 the request has to originate from Service provider, most Enterprise IDP's rely on SAML for Single Sign on cause of its ability to do IDP initiated flows
2. The security for SAML is baked into the payload itself, provides safety against MITM attacks, even though the HTTPS provides similar guarantees in theory, the reality is that your SSL offloading happens elsewhere, not on your application server
The OP provided a list of vulnerabilities discovered in SAML, IMO this kind of comparison if flawed if you do not present the same for OIDC/OAuth2.
At the end of the day, these are tools and effectiveness of a tool is a lot dependent on ones skillset to understand and use the tool.
bawolff · · focus · HN ↗
This is just as true for JWT. Actually its a lot more true for JWT as people usually implement this wrong in SAML.
Additionally, https doesn't really protect you here, as typically the user sees the token/saml document, and they are the main party you have to worry about being in the middle.
> this kind of comparison if flawed if you do not present the same for OIDC/OAuth2.
i'm doubtful there are any vulns in oidc/oauth2 that aren't present in saml. SAML vulns are typically a strict superset of oidc vulns.