ES version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
40% Positive
Analyzed from 1613 words in the discussion.
Trending Topics
#saml#oidc#xml#authentication#security#design#works#actually#support#don
Discussion (32 Comments)Read Original on HackerNews
The article rightly connects this to XML, which was indeed the hammer to everything’s nail at the time
I think we aren’t done with this problem yet, though. OIDC makes a lot of assumptions in service to Google and others. And tailscale as mentioned, despite “holding the line,” already reveals the cracks when things like GitHub accounts have to be treated differently from others.
What we are missing is a provider-independent way to do this. I should be able to create an account and log in just about anywhere using a backend I control. It can be done, but not with what we have today
"Host your own identity"
I mean … how else would you check a signature? You have to have the data to validate the signature.
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.
Anyone who has used Wireguard and OpenVPN will spot the difference. OpenVPN is the design-by-committee, Wireguard is the focused opinionated design by someone with a vision. OpenVPN does more things, but if your use case is one that suits Wireguard, Wireguard does it much better.
You also see it with OSI stack versus IP. OSI invented all these layers for proving identity, establishing circuits, sessions, different billing models, collect calls, quality of service, all that stuff. IP looked at that and said: fuck that noise - we send packets, if they don't arrive we send them again, job done. Nobody uses the OSI stack, even though IP fits the OSI model loosely enough that they still teach it, and X.509 got reused as boilerplate for WebPKI certificates.
XML vs JSON is another one. Granted marked-up text, which XML was actually designed for, is very ugly in JSON, but even in that use case, XML has way too much complexity.
If the IP, Wireguard or JSON people designed an SSO system you'd telnet or HTTP into the authenticating party, perform its login steps, get a token you could copy-paste into the relying party and it would check back with the authenticating party to see if the token is valid and the username of the person who signed in - done. And then someone would make a browser extension to automate the copy-paste part. Or maybe they'd embed it in an iframe. Instead we got whatever the hell this is.
Protocol complexity is where bugs hide, including vulnerabilities. It also creates incompatibility wherever two implementations implement it differently - and that's intentional in many cases. It's just bad. You have to be opinionated about what you design or you designed nothing at all. If it doesn't fit all use cases you can design something else to cover the rest.
We should remember that we learn by failing.
Edit: When I first read the comment, XML part was not there, but I don’t agree with the XML part of the comment, because JSON to XML is Python to C. While both can carry data, XML is designed to handle more than that. Especially validation and transformation parts. If you don’t need these, it’s an overkill, but if you use them, it’s a perfectly fine format. It’s even elegant and batteries included.
Also, you can parse it in an instant. I have designed XML based file formats which would fall apart in JSON and YAML.
The XML debates sounds to me like calling a space shuttle complex because one only needs to go to the mall downtown.
I'm almost convinced already, but I have the professional duty to at least read why
>SAML is an XML-based
Ok, I'm convinced
Oauth2 is utter utter shite as well.
(Or to be more clear, it is mostly unacceptable for an enterprise product to have opinionated decisions about what authentication it works with. You either work with what we use or you are not viable as a product for our need. It's kinda simple. I would expect someone whose authentication was OIDC-based to be similarly dismissive if you told them you only would do SAML.)
Pretty much everything supports SAML. If you decide not to support one of the standard protocols for SSO, you'll lose out on customers. Your tool has to bring in a lot of benefit (and have no competition) to warrant upending a company's entire auth system for.
1. "You either work with what we use" - so whatever organization you represent isn't capable of evaluating and shifting to more secure technologies?
2. "it is mostly unacceptable for an enterprise product to have opinionated decisions about what authentication it works with" - you think companies that care about security should not care about integrating with flawed protocols?
A potential customer making bad choices does not obligate a business to make bad choices for their business.
As a SaaS vendor, interacting with our customers about SAML usually involves:
a) them knowing what they want because they already have SAML-based SSO and it works for them; and
b) our contact on their side being some unfortunate support dude who got given SAML as their subject area for whatever reason, and who knows very little about it, and who is 4 levels in the org away from anyone empowered to make decisions as significant as moving away from SAML.
1. Finding out a company wants several grand to flip the "allow SAML" switch on the tenant config, and a few thousand a year in additional licensing to leave it on. (I had a vendor both tell me it "takes five minutes" to get it set up, and then quote me $4,800 to "implement" it.)
2. Having to yell at the SaaS vendor for routing the identity connection between two or three other identity providers in different various clouds because, you know "modern stuff". (A vendor I am working with has not less than five different accounts to access various parts of their infrastructure, none of which are connected at all. I assume people there listened to "switch to OIDC" nonsense, completed half the job, and now have OIDC sites and SAML sites forever.)
3. Discovering the SaaS vendor knows how Entra works, how Okta works, and how Google auth works, and having no idea how SAML works. Or OIDC or anything else for that matter.
4. Eventually finding an engineer far enough from the sales and implementation teams who can answer how the product actually works. :D This point is reached after a lot of yelling.
Indeed it does not. If you feel that strongly that you are willing to lose out on that customer, that's your right. But that does not mean the foregone customer is unreasonable for expecting you to work with their constraints in order to get their business.
If you are a vendor, you should have SAML support unless you are early (and can only support 1 standard), or you are highly opinionated.
If you are a consumer instead, you will only be using one standard, so you HAVE to chose 1 and not the others.
Saml is just not reasonable in our modern security environment.
https://www.war.gov/News/News-Stories/Article/Article/428899... (Microsoft has solely discontinued this practice for the DoD tier. Commercial, GCC, and GCC High are still impacted because foreign labor is cheaper than the risk to your security.)
The XSW part of the article was new to me though and kinda shocking
OAuth/OIDC is a problem if you're trying to shove a bot-shaped peg into a browser-shaped hole, but we don't need a new protocol to solve that.
If my security system is showing friction when there's a wave of agentic slop, I'd say that's a win.