This is a very weird page, as it seems to suggest that SAML is the only way to do single sign-on integration with IdPs like Okta. But modern systems all do OIDC, which is what you should do. You need a much better reason to support SAML than "the CISO wants it so they can use Okta", because the CISO can (and should) just use OIDC.
OIDC is better when using the authorization code flow because it does not only rely on cryptography while validating the token. The relying party needs to talk to the IdP. This is better from a security perspective, because past vulnerabilities have shown, that implementing the cryptography right in every relying party is challenging. You can achieve similar security with SAML when using the artifact binding.
Note: I work professionally with Keycloak and also offer reviews of OIDC and SAML implementations.
SAML is an unfortunate a necessity in most enterprise environments. There’s almost always something, usually more than one, where SAML is the only option. I do think in 2024, everyone should also offer SAML alternatives in parallel
.
Sure, but that would arise because you've followed the advice in the article.
If you're a relying party, and you want to integrate with Okta, Google, other OIDC-supporting IdPs … implement OIDC!
If you're on the RP side and you have to integrate with an IdP that only speaks SAML and not OIDC, well, then you're probably out of luck and just have to make the call: is it worth the business? Maybe it is. Then you implement SAML.
I don't think artifact binding really addresses many of the issues people are talking about when they suggest OIDC is categorically more secure than SAML.
OIDC is newer and many of the issues with SAML were addressed in the architecture. However I’m curious to hear which attack vectors you are thinking about.
A common pattern of SAML vulnerability is one that allows logins from one org access to resources of another org, which is not mitigated by trusting IdP's.
PKCE (specifically the S256 method, but that's the one that you're supposed to implement in almost all cases) is by itself a cryptographic method, but there are few points to note here:
1. PKCE relies on very simple cryptography that is hard to implement incorrectly. There is only is only one protocol defined (SHA-256), and that protocol is considered safe. Allowing the "plain" protocol in the RFC was silly, but we were lucky that the RFC writers didn't go full bonkers like they did with JWT, and started digging up ancient ciphers in case someone really wants to run PKCE on a WW2 vintage Enigma machine. In short, PKCE has no weird or old cryptography.
2. PKCE is not considered mandatory or even recommended for confidential clients prior to OAuth 2.1 (which is still a draft). It is rarely implemented in these cases.
3. You cannot use JWKS for PKCE. I believe you are confusing PKCE with the ID Token, but the GP was specifically talking about the Authorization Code flow, where the ID Token doesn't really matter. If you're using that flow an unfortunate piece of over-engineered industrial waste[1], but if you're using the Authorization Code flow it doesn't matter: even if the ID Token is completely broken, it cannot hurt you, since you must have a correct authorization code to get it in the first place.
4. Even if PKCE itself gets broken somehow (the main risk being an IdP that allows downgrade attacks), this only makes the protocol vulnerable to CSRF on confidential clients. Only on public clients that rely on custom URL schemes (such as native apps), this can lead to a more serious exploit.
[1] Sadly, this is coming from the same people who wrote the PKCE spec. On one hand they think your system might be too constrained to support SHA-256, so we need to add the "plain" algorithm, but on the other hand, they make RSA signatures (including SHA-256!) a mandatory part of the Open ID Connect spec through this totally unnecessary token.
Another thing to mention, as I have in the past[0], is that SAML is frozen in time and will no longer be updated. The link in that HN post has TLS errors now, but it says:
> At the request of the members, the Security Services (SAML) TC has closed.
There are tons of orgs that have built SSO on SAML so it won't die for a long time, but it's a frozen standard. From my understanding, it's frozen because no one wanted to put in the time to improve it.
OIDC doesn't scale, and OIDC Federation is still in draft. SAML Federation is mature with wide support and good discovery UX thanks to SeamlessAccess.
SAML has a variety of standard attribute bundles, entity categories, frameworks, and profiles covering important integrations, e.g., identity assurance. These are slowly being defined in (or ported to) OIDC.
I like OIDC and think highly of the people working on it, but it's nowhere near as cut and dry as you suggest.
I don't know a lot of security engineers that agree, and while (as a SAML implementor) I have my own opinion, "don't do new SAML implementations" is mostly me parroting what I think is the consensus.
I think... it probably is as cut and dry as I'm suggesting.
This cuts both ways. The last major revision of SAML predates the iPhone by several years. Things like PKCE, which are essential for security on mobile devices and in other cases don’t exist at all in SAML, yet the same attack vectors apply (plus a boatload more).
The things you just listed sounds like unnecessary complexity that inevitably leads to the “too big standard” problem, where every vendor and id provider has their own half assed, incomplete and incompatible implementation of the standard, or worse - with security bugs. Something quite often seen with SAML.
That’s not to say that oidc or oauth doesn’t have alignment issues. See https://news.ycombinator.com/item?id=35713518 “We implemented OAuth for the 50 most popular APIs. TL;DR: It is still a mess”
> Let's just say my interaction with managing websites that used SAML was less than pleasant.
My interactions supporting it as both the identity provider & the service provider have lead to me being the SAML person at work, and I'm now very used to people either laughing at my misfortune or giving me pitiful looks.
It combines all the wonderful antipatterns you can name: a protocol where near everything is optional and two standards-compliant implementations can refuse to cooperate in any number of ways, hair raising security decisions (XML-DSIG?! configurable crypto? ughh), and half-baked features (back-channel SLO, anyone?)
It's a Lovecraftian horror that actually makes me appreciate JWTs.
Yes, JWTs are so simple compared to what came before that it's hard to argue with them. Just make sure your verification doesn't allow none or old ciphers and you're basically fine.
I was also the SAML person at one point in my career and I 100% agree. I used to laugh at all the HN criticisms of JWT because of how much of a nightmare SAML is.
Do you renew the certificates used to distribute the public keys in SAML metadata, and if so why do you do it? I have had a hard time convincing people it is useless to renew those certs and have yet to find an implementation that care about those certificates.
Renewing the certificates seems technically pointless, but some organizations/federations require it.
Rotating the keys would make some sense, but just swapping the cert for a new one issued against the same keys doesn't. It's the easiest way to fulfill those requirements, because you don't need to synchronize the metadata updates, the signatures are always valid with both the old and new cert.
As someone who worked at a very large SaaS company this is a good recommendation if the vast majority of your customers come from large enterprises with competent IT departments.
The problem is when you work with smaller shops that don’t have IT departments or worse bad IT departments you’re going to pay a fortune in support costs.
Use an open source identity provider or pay someone to do it for you.
Everyone in here is saying SAML is dead and long live OIDC. The company I work for has SAML support, but not OIDC. As far as I understand it, all the customers are asking for SAML. I've never heard a request for SAML. This is in the health care sector.
I also work in healthcare. There are some entities out there doing OIDC, but SAML is pretty popular, unfortunately.
Healthcare, as an industry, is not making decisions based on what constitutes "good engineering", for the most part. There are so many other things I'd burn to the ground that are just ancient, ass-backwards things that the rest of the industry has moved on from, but healthcare clings to. (…IPSec, for example. God I'd like to not have to do double-NAT'ing with providers who don't even understand NAT and just expect me to recognize IP addresses that are only internal to their network and never exposed to me, ever again.)
I implemented SAML SSO for Django at my prev company about a year ago. I procrastinated for a few months and by the time I implemented it, the whole company started retiring it in favor of OIDC. I was about to do that too but I quit right before. Looked much easier to do OIDC with Django. Seemed like SAML was on the way out in general, even Django extensions weren’t prioritizing it and information resources for implementing SAML weren’t great. Long live OIDC I guess.
I have implemented the server-side of OIDC to support the single sign-on for AWS account management. It was a breeze, around 200 lines of Go code.
I tried that with SAML (back then, it didn't require kludgy X.509 thumbprint management in AWS), and I ran away crying after a couple of days trying to understand why it fails.
The problem is not XML by itself. XML adds a considerable amount of complexity to JSON[1] and when writing security-oriented software complexity matters quite a bit[2]. But this is still a level of complexity that can be managed. Most other XML-based protocols aren't as bad as SAML.
No, the main problem with SAML is that it relies on XML Signatures (XMLDSig). And the main problem with XML Signatures is that the signature needs to be embedded inside the XML it's signing, instead of being attached to it, like every other signature standard on the planet.
[1] The added complexity is not just attributes and namespace, but also entities, DTD and processing instructions. If you want even the most basic type checking, XML schema becomes mandatory. This is important, since JSON doesn't need a schema for handling basic types, and in fact OAuth 2.0 and Open ID Connect do not rely on JSON Schema at all.
I really wish that OIDC / Oauth(orization) would be less confusing from user experience and security perspective.
What I have in mind - I'd say only very small population understand that OIDC / Oauth(orization) is about granting access to a service to access your data. Meaning once you have approved service (lets say Dropbox), now Dropbox can access your data on your google account (this of course depends what exactly dropbox asked and if you clicked on "approve", but most people do click as they want to login to Dropbox via their Google account).
SAML is better, as it can be defined at Google side what data is being sent to DropBox when Single Sign On happens and DropBox cannot access your google data as it sees fit.
SAML ain't perfect either because there's no practical way to "sign me out everywhere"
That was my understanding and also my plan, but it does not seem feasible to force this as the vendor of the software. If the customer says they need SAML at some point the business side will require that it is implemented. I do want to try and get as far with only OIDC as possible, but I am a bit worried that some larger customer might just bulldoze through because they only want SAML. Might be much more likely for on premise cases, if you're in the cloud you probably use an identity provider that supports OIDC already.
We've managed to hold the line on OIDC so far. So has Tailscale. If Tailscale can hold the line, given who they're selling to, I think most orgs can. Really, try to avoid doing SAML. Remember, as a vendor, you're often competing with companies that don't do real SSO integration at all.
At the very least: if I was ever to do SAML, I would rip your face off in the pricing for it.
If by "we" you mean Fly, can you tell me if Fly happens to be implementing OIDC (or reusing a third-party implementation) in Elixir, Ruby, or another language? I'm curious about what Fly in particular is using because I know that Fly has invested pretty substantially in Elixir and Phoenix in particular, and I've got a Phoenix app where I want to implement OIDC. We previously implemented SAML by literally using Shibboleth SP. Thanks.
It's not just XML formatting; it's bizarro stuff like XML canonicalization and comments, and it's in a signature format. It really might be the worst mainstream cryptosystem in the entire industry.
Microsoft Entra having first class support for OIDC really helps; I remember seeing a decision diagram in their documentation recommending using OIDC for new projects, it can help negotiating. Google Workspace also works just fine with OIDC, and so does Okta.
I've been told that the only source of problems is going to be companies using Shibboleth, even though there seems to be an OIDC plugin.
Yeah, SAML will probably fade away (slowly). And sometimes, you might be able to convince the customer just to use OIDC.
But human behavior change is hard and expensive. For the most part, it's just easier to give the customer what they're asking for / what they expect, even when you know they're wrong.
When you're trying to push an enterprise deal over the finish line, this is often just not a good enough reason to introduce friction with your buying committee.
And if you have to support SAML for one stubborn customer eventually, you might as well support SAML for all customers that really want it.
Cryptographically authenticating SAML assertions is the most perilous part of implementing SAML
The incredible overengineering of the XML signature specification is certainly to blame for this recent SAML verification vulnerability (from the same site): https://news.ycombinator.com/item?id=41586031
OIDC is far preferable to SAML, but the last time I touched this, half the reason why customers preferred SAML was because their IdP supported SCIM but only for SAML applications.
Yeah, I didn't even mention the other bindings (HTTP-Redirect, Artifact, etc.) because they're not widely supported. Only SAML's HTTP-POST binding enjoys "every IDP supports this exact protocol" status.
FWIW, the for library I work on -- github.com/ssoready/ssoready -- we sidestepped this issue by simply not using SAML RelayState at all under the hood. Between the fact that it's vulnerable to attacker manipulation, and the size limits, it's not worth the pain. We just implement SAML RelayState / OAuth `state` via good old database persistence.
Since we're here, I hope someone creates another all encompassing SP/IDP emulator like samltest.id used to until the owner stopped paying. That made my life so much easier as a developer when SAML stuff came up. No one else has come close.
FWIW back in the day, samltest.id was a dummy IDP, whereas sptest.iamshowcase.com is a dummy SP. You could hook these two up to each other and see the whole flow.
> You care about supporting SAML because your customer wants your product to support SAML. This is sound reasoning on your part. But why does your customer want SAML support?
> One click to login: why your users like SAML
What? No, the users don't know about SAML.
Anyways, no, users don't like SAML. OIDC has a much nicer UX.
They specifically said "customers" not "users" and in my experience (healthcare) they're correct. Being able to tell customers IT departments you support SSO via SAML goes a long way towards getting a purchase approved.
If you're a relying party, and you want to integrate with Okta, Google, other OIDC-supporting IdPs … implement OIDC!
If you're on the RP side and you have to integrate with an IdP that only speaks SAML and not OIDC, well, then you're probably out of luck and just have to make the call: is it worth the business? Maybe it is. Then you implement SAML.
Browser sends artifact to RP, RP fetches assertion from IdP via HTTPs, afterwards verifies the signature.
Signature verification is not implemented correctly? The attacker still needs to break HTTPS…. And then you would have a big problem anyway.
When using PKCE the relying party can use JWKS to validate the token instead of talking to the IdP.
Are you suggesting that, that is somehow insecure?
1. PKCE relies on very simple cryptography that is hard to implement incorrectly. There is only is only one protocol defined (SHA-256), and that protocol is considered safe. Allowing the "plain" protocol in the RFC was silly, but we were lucky that the RFC writers didn't go full bonkers like they did with JWT, and started digging up ancient ciphers in case someone really wants to run PKCE on a WW2 vintage Enigma machine. In short, PKCE has no weird or old cryptography.
2. PKCE is not considered mandatory or even recommended for confidential clients prior to OAuth 2.1 (which is still a draft). It is rarely implemented in these cases.
3. You cannot use JWKS for PKCE. I believe you are confusing PKCE with the ID Token, but the GP was specifically talking about the Authorization Code flow, where the ID Token doesn't really matter. If you're using that flow an unfortunate piece of over-engineered industrial waste[1], but if you're using the Authorization Code flow it doesn't matter: even if the ID Token is completely broken, it cannot hurt you, since you must have a correct authorization code to get it in the first place.
4. Even if PKCE itself gets broken somehow (the main risk being an IdP that allows downgrade attacks), this only makes the protocol vulnerable to CSRF on confidential clients. Only on public clients that rely on custom URL schemes (such as native apps), this can lead to a more serious exploit.
[1] Sadly, this is coming from the same people who wrote the PKCE spec. On one hand they think your system might be too constrained to support SHA-256, so we need to add the "plain" algorithm, but on the other hand, they make RSA signatures (including SHA-256!) a mandatory part of the Open ID Connect spec through this totally unnecessary token.
> At the request of the members, the Security Services (SAML) TC has closed.
0: https://news.ycombinator.com/item?id=41056529
There are tons of orgs that have built SSO on SAML so it won't die for a long time, but it's a frozen standard. From my understanding, it's frozen because no one wanted to put in the time to improve it.
OIDC doesn't scale, and OIDC Federation is still in draft. SAML Federation is mature with wide support and good discovery UX thanks to SeamlessAccess.
SAML has a variety of standard attribute bundles, entity categories, frameworks, and profiles covering important integrations, e.g., identity assurance. These are slowly being defined in (or ported to) OIDC.
I like OIDC and think highly of the people working on it, but it's nowhere near as cut and dry as you suggest.
I think... it probably is as cut and dry as I'm suggesting.
The things you just listed sounds like unnecessary complexity that inevitably leads to the “too big standard” problem, where every vendor and id provider has their own half assed, incomplete and incompatible implementation of the standard, or worse - with security bugs. Something quite often seen with SAML.
That’s not to say that oidc or oauth doesn’t have alignment issues. See https://news.ycombinator.com/item?id=35713518 “We implemented OAuth for the 50 most popular APIs. TL;DR: It is still a mess”
Factually incorrect
Frankly I’d suggest the same thing about Okta but as bad as they are whatever you do to avoid them would probably be worse in practice.
"Suffering A Massive Lot" - jk
Let's just say my interaction with managing websites that used SAML was less than pleasant.
My interactions supporting it as both the identity provider & the service provider have lead to me being the SAML person at work, and I'm now very used to people either laughing at my misfortune or giving me pitiful looks.
It combines all the wonderful antipatterns you can name: a protocol where near everything is optional and two standards-compliant implementations can refuse to cooperate in any number of ways, hair raising security decisions (XML-DSIG?! configurable crypto? ughh), and half-baked features (back-channel SLO, anyone?)
It's a Lovecraftian horror that actually makes me appreciate JWTs.
Rotating the keys would make some sense, but just swapping the cert for a new one issued against the same keys doesn't. It's the easiest way to fulfill those requirements, because you don't need to synchronize the metadata updates, the signatures are always valid with both the old and new cert.
The document is open source: https://github.com/ssoready/docs/pull/55
The "Continue with" buttons that include Microsoft, Google, and Apple, tend to pick up most SMBs without SAML SSO headaches on either side.
Like so:
https://www.xsplit.com/user/auth
https://id.atlassian.com/login
Use an email domain restriction, and you have by and large SSO; the user can only log into your SaaS if the user is an active account at that company.
Storing user passwords yourself is a liability, indirect or direct: https://www.reuters.com/technology/eu-privacy-regulator-fine...
The problem is when you work with smaller shops that don’t have IT departments or worse bad IT departments you’re going to pay a fortune in support costs.
Use an open source identity provider or pay someone to do it for you.
Healthcare, as an industry, is not making decisions based on what constitutes "good engineering", for the most part. There are so many other things I'd burn to the ground that are just ancient, ass-backwards things that the rest of the industry has moved on from, but healthcare clings to. (…IPSec, for example. God I'd like to not have to do double-NAT'ing with providers who don't even understand NAT and just expect me to recognize IP addresses that are only internal to their network and never exposed to me, ever again.)
I tried that with SAML (back then, it didn't require kludgy X.509 thumbprint management in AWS), and I ran away crying after a couple of days trying to understand why it fails.
Apples to apples, is it's not much different. XSD is just as complex as JSONSchema.
Verbose? Sure.
But people love XML so much, they invented JS-and-XML (JSX). :shrug:
No, the main problem with SAML is that it relies on XML Signatures (XMLDSig). And the main problem with XML Signatures is that the signature needs to be embedded inside the XML it's signing, instead of being attached to it, like every other signature standard on the planet.
[1] The added complexity is not just attributes and namespace, but also entities, DTD and processing instructions. If you want even the most basic type checking, XML schema becomes mandatory. This is important, since JSON doesn't need a schema for handling basic types, and in fact OAuth 2.0 and Open ID Connect do not rely on JSON Schema at all.
[2] See the OWASP cheatsheet for all the ways accepting XML input from the internet can put your application in danger: https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_...
No equivalent document exists for JSON.
What I have in mind - I'd say only very small population understand that OIDC / Oauth(orization) is about granting access to a service to access your data. Meaning once you have approved service (lets say Dropbox), now Dropbox can access your data on your google account (this of course depends what exactly dropbox asked and if you clicked on "approve", but most people do click as they want to login to Dropbox via their Google account).
SAML is better, as it can be defined at Google side what data is being sent to DropBox when Single Sign On happens and DropBox cannot access your google data as it sees fit.
SAML ain't perfect either because there's no practical way to "sign me out everywhere"
At the very least: if I was ever to do SAML, I would rip your face off in the pricing for it.
A computer programmer wouldn't even know where to begin, as the chesterton's fence had long been rejustified
I've been told that the only source of problems is going to be companies using Shibboleth, even though there seems to be an OIDC plugin.
But human behavior change is hard and expensive. For the most part, it's just easier to give the customer what they're asking for / what they expect, even when you know they're wrong.
When you're trying to push an enterprise deal over the finish line, this is often just not a good enough reason to introduce friction with your buying committee.
And if you have to support SAML for one stubborn customer eventually, you might as well support SAML for all customers that really want it.
The incredible overengineering of the XML signature specification is certainly to blame for this recent SAML verification vulnerability (from the same site): https://news.ycombinator.com/item?id=41586031
OIDC is far preferable to SAML, but the last time I touched this, half the reason why customers preferred SAML was because their IdP supported SCIM but only for SAML applications.
> As well in "HTTP Redirect Binding" or "HTTP POST Binding", The RelayState value MUST NOT exceed 80 bytes
From https://docs.oasis-open.org/security/saml/v2.0/saml-bindings...
At FusionAuth, we have an open issue for this: https://github.com/FusionAuth/fusionauth-issues/issues/2467 which you can read for more details.
SAML is full of these kinds of gotchas. We have an open source library which provides Java SAML bindings: https://github.com/FusionAuth/fusionauth-samlv2
FWIW, the for library I work on -- github.com/ssoready/ssoready -- we sidestepped this issue by simply not using SAML RelayState at all under the hood. Between the fact that it's vulnerable to attacker manipulation, and the size limits, it's not worth the pain. We just implement SAML RelayState / OAuth `state` via good old database persistence.
Is it just me or is anybody else going 'the fuck did I just read?' here? It's... incredibly condescending?
N. a complicated or unpleasant situation from which it is difficult to extricate oneself.
Indeed.
(Well, used : in luckily no longer in charge of an IdP with a bespoke SAML implementation so I don’t need to deal with this crap anymore!)
> You care about supporting SAML because your customer wants your product to support SAML. This is sound reasoning on your part. But why does your customer want SAML support?
> One click to login: why your users like SAML
What? No, the users don't know about SAML.
Anyways, no, users don't like SAML. OIDC has a much nicer UX.