If given the option, go with OpenID Connect instead. Both the OIDC and SAML standards are overly complex and designed to accommodate more use cases and enterprise configurations than they should. That said, OIDC is based on OAuth 2 and does not depend on XMLDSig. That's a win, in my book. OIDC library support is good, and getting basic federated login working for common patterns is relatively easy.
Is anyone going around choosing SAML today, though? XML fever has come and gone.
Usually SAML happens because customers ask for it, OIDC isn't as widely implemented by IDPs as SAML is, so you end up implementing SAML and moving on with life.
I love to see OIDC gaining traction, though I will say that for setting up any sort of custom workforce federation, the administrative experience for OIDC applications often feels like an afterthought. I haven’t looked at all implementations, but I have recent experience federating SAML and OIDC applications in Okta, Google Workspace, and Entra ID.
Amazon also has pretty explicit preference for SAML if you want to fine-grain certain things, it's much easier if you need to connect AWS to external SSO without going through AWS SSO (which, last time I checked, had to be "global" thing for whole fleet of accounts, which makes problems when you need some sub-accounts to have different SSOs)
They say this in how you simply are limited in what you can pass and control when using OIDC Vs SAML.
SSO -> token that works only for specific role, where the specific user is supposed to be able to take many roles, is very hard to do with OIDC unless you can mangle OIDC tokens properly, whereas it's way simpler to do with SAML
I'd love to read about that more if you can share links explaining those details.
Whatever you've described sounds more like internal problems / challenges of their own implementations than anything else... especially the OpenID Connect as a delegated authentication protocol itself.
It's been over 2 years since I dealt with it, but in essence the details boiled down to much bigger size limits for SAML assertions vs. how big a JWT token could be passed to AWS STS for AssumeRole call. 100000 characters of base64 vs few kilobytes of JWT, an error we hit very very early.
Also, for practical purposes, you can parse available roles out of SAML2 response from IdP, presenting a menu to the user asking them to select the right role.
To deal with OIDC having way smaller space for "assertions", I ended up adding extra parameters to OIDC login request, and modified our IdP (keycloak) to parse it and filter user's groups (set from AD) to only include the group passed in parameter. This way we could always "fit" inside OIDC token limits in STS.
This was in regulated environment where users had to be given very fine grained access, and simultaneously could have many, many, many roles available - and had to be able to switch between them at runtime. I think we blew the STS the moment we fed the IdP with real group membership dataset instead of the less than 10 groups we had used in tests. Don't recall if it also didn't trigger some really hilarious errors that I recall seeing, like Sagemaker exploding with EC2 ENI attachment errors, but that one could have been triggered by something else.
If we look a bit closer, we notice that the first four use OpenID Connect under the hood. These names are fancy names for OpenID Connect with a little bit of something extra on top from Apple, Google, and so forth.
AWS SSO, ASS Cognito, and SSO (SAML/OIDC) integration in AWS IAM/STS are all three different things, with separate behaviours, problems, typical Amazon undocumented pitfalls, etc.
I second this. OIDC is much nicer and my experience using it with federated identity sources through AWS Cognito was smooth. The sad reality is that SAML is already entrenched in many enterprise environments and unavoidable.
Unless your customers are primarily in higher education/research, then just take the time to figure out SAML. Higher ed collaboration requires eduGAIN, which requires SAML (because SAML has mature multilateral federation support).
I believe they will eventually. But first, the spec needs to be finalized (in progress), implemented in all the libraries that need to support it (some in progress, some unaware this is coming), and deployed by all federation managers and members worldwide (planning in progress). I'm excited for OpenID multilateral federation, but it's going to coexist alongside SAML for an excruciatingly long time. Probably not as long as IPv4 or Python 2, but the better part of a decade seems plausible.
This sounds like a complaint with Google's implementation, not with OAuth in general. The correct scopes should limit information sharing to the user's profile. All of the security and privacy concerns that necessitate an explicit user interaction apply to SAML too.
That's the thing - authentication capability is basically sideeffect of Oauth/OIDC.
SAAS x can request whatever they want via OIDC and then user can either accept it or decline it. This is protocol, not google specific matter. Ask ordinary user how they understand what is being asked from them when they are trying "to log in" via OIDC/Oauth.
With SAML it's the other way around - administrator chooses what is being sent to SAAS x, user does not need to decide anything nor do they get hard to understand prompts.
I'd say the main difference is that OAuth is granting the SP the ability to "do stuff" as the original user (including reading the user's profile details, as OIDC does), as opposed to SAML's approach of just sending attributes describing them.
For what it's worth, it is certainly possible for SAML SPs to flag that certain attributes should/must be released to them via their metadata, but the actual release is at the whim of the IdP and its operators. It's also possible for a SAML IdP to expose that level of detail to its end users and allow them to agree/disagree to the attribute release, although I'd be surprised if that behaviour was particularly common in practice.
The difference between OIDC and OAuth boils down to exchanging attribute assertions describing a user as opposed to the delegation of a specific set of allowed actions, as OAuth was intended to do. OIDC and SAML are basically the same thing, with OIDC being a somewhat less frightening and more modern protocol.
Reading the user's profile information _is_ the delegated action. OAuth providers were already doing this prior to OIDC but in incompatible ways. OIDC standardized how that information is requested and returned.
Should, but don't. OAuth2/OIDC implementations tend to be way more transparent about the asks being made between an IdP and SP. It can be confusing. (I agree, however, it's the right path.)
You can't compare OAuth with SAML. OAuth is authorization and comes only ever after authentication, which is OIDC.
But to respond to your critic: It is good that apps let you know that you are IN FACT not merely logging into something, but grant that app access to your Google Drive. This is a very important information! Imagine your mom signs into ClashOfClangs (a malicious clone) and the IdP would in fact NOT tell your mom that the app will have access to all her files because it may be confusing
Unlike SAML's "take this assertion" IdP-initiated flow, OIDC went for a "start an authentication with this IdP, for this user, and send them back here". Much, much safer.
The "OIDC way" would be an endpoint on the service provider ("relying party" in the spec) that immediately redirects into authentication. The spec does have a section describing this.
IDP-initiated flows are less secure, as they cannot prevent unsolicited logins. Last time I checked Google went as far as to block this flow in their Firebase Auth product.
While designed to accommodate many use-cases (which ist Not a bad thing), I'm curious what you seem overly complex? They're both pretty straight forward (except for single logout in SAML, which was never truly resolved and just left to die)
XML-DSIG is probably one of the 3 worst cryptosystems ever designed (don't ask me what the other two are, I'm just sure XML-DSIG is one of them) and the system is so complicated that a huge percentage of the deployed base of SAML systems, regardless of their language and library choices, backend onto the same ancient libxmlsec codebase.
If I could avoid doing SAML (we have so far!), I would avoid doing so as long as I could.
Agreed. XML Signatures is the worst part of SAML. It's a spec that's basically begging to be done wrong. I remain confused as to what W3C were thinking.
SAML literally predates most modern cryptography, including basic notions like the inseparability of encryption and authentication. It's a backwater that until relatively recently was confined to clanking enterprise deployments, and OIDC means it will never be modernized; the "next modernizing step" would be to simply turn it into OIDC.
I was so afraid of getting my SaaS's SAML implementation wrong that I decided to run Shibboleth SP, which is basically the reference SAML service provider implementation, even though that practically meant running Shibboleth SP and Apache httpd in a separate container, with a small Python WSGI app running under Apache to basically redirect back to an endpoint in the main app. (I didn't want to run the whole main app behind Apache just to support the SSO use case.) This was three years ago, and at the time we especially wanted to sell to the academic market, so I think SAML was still pretty much a requirement.
Are any of the big IdP's (Microsoft, Google, Okta, etc.) still SAML-only?
They all support OIDC, though in my experience, it’s moderately more clunky to deploy unless a “blessed” integration exists in the app store/directory. Okta provides the best experience of the three. Google Workspace admins have to drop out to Google Cloud to federate an app that’s not in the OIDC store. Entra ID falls somewhere in the middle between the two.
Why clunky? I can only talk about Microsoft, but they follow the specs and I found nothing clunky about it, because following the RFCs, everything worked exactly as expected .
Why clunky? I can only talk about Microsoft, but they follow the specs and I found nothing clunky about it, because following the RFCs, everything worked exactly as expected
> backend onto the same ancient libxmlsec codebase
If anyone is looking for SAML bindings and is using java and wants to avoid libxmlsec, my employer has an open source set of bindings for processing SAML requests: https://github.com/FusionAuth/fusionauth-samlv2
While the difficulty of achieving single logout (SLO) is interesting technically, we can zoom out a bit and see that SLO died because all web logout processes are pointless given how screen lock and user switching have become ubiquitous. It hasn't always been the case, but it is now. If you're letting someone use your OS session, they can auto-fill passwords from your password manager, maybe install a keylogger, who knows what else. You must lock your OS session, at which point you can keep web sessions logged in.
Are they config time issues or runtime? That is to say, do the issues occur when you are integrating a new customer, or are they with current customers where something changes or pops up and there's an issue?
The most common problem is they forget to upgrade their yearly certificates or mess up the deployment. Other times they don’t have their servers correctly configured to read our manifest and thus miss certificate updates from our side. Or they mess up the payload configuration so we don’t receive the principal.
I'm curious - what is the issue with XMLDSig? I think XML is kind of a mess with the whole "billion laughs" attack, but other than that, are there problems with DSig that I don't know about?
In addition to reasons shared by other commenters, my main concern is XML Signature Wrapping.
XMLDSig APIs are not well designed. They check whether signatures in a document are valid, but signatures are not required to cover the entire document. XMLDSig APIs do not make it easy to confirm that signatures cover a specific element of interest, like saml:Subject.
An adversary can stuff a valid assertion within a forged one, and many popular SAML implementations would accept the forged assertion. This is mostly fixed now, but it's still one of those things that I must validate for myself in all new SAML service providers that I can influence.
Try implementing XMLDsig yourself and you'll quickly learn how awful it is. Aside from the other comments mentioned in these replies, one of the horrible things about XMLDsig is that it requires you to mutate ("canonicalize") the XML that is to be signed. Then, the signature is injected into the document that was signed ... to be removed by the verifier before it has to canonicalize the document, etc, etc
There's a wealth of issues, some generic and some specific to the (not so well thought out...) choices made by the SAML spec.
For starters, the XML signature spec requires canonicalization of the message (which is XML). But the message itself need not be the canonicalized message. So the SAML implementer, if they follow the spec, must process the untrusted input and canonicalize it prior to verifying the signature.
Add in that you can override just about every aspect of the signature algorithm, canonicalization details, and even what parts of the message are actually signed, and you get huge number of places where things can either go wrong or may be overlooked.
Then throw in "XML Encryption" (again with canonicalization) which could be done on the whole message or just the assertions.
Then throw in that you can sign the encrypted portion, or the unencrypted portion, or just the assertions, or encrypt the signatures, or ...
So in short, there's too many ways to do too many thing.
Which leads to a massive surface area of code if you actually follow the spec. Which leads to libraries that either do not follow the spec (e.g., ignoring encryption and just checking signatures in a known location), or think that they follow the spec but will happily ignore missing assertions or out of date certificates.
SAML sucks. But hey, it's still better than having your own passwords!
There's also detached signatures and flexible tag matching, which lead to implementations that have provide rigid schemas with semantic passes to make sure there's no place to smuggle either additional signed content to confuse verifiers, or content that will get signed that changes the message semantics. The whole thing is deeply unsound. OIDC is no great shakes, but even 10 years ago nobody would ever design a signed message scheme that looked like SAML.
Outdated certificates are actually fine with regards to SAML, oddly enough; the logic being that the trust is handled out of band at metadata level, and the certificate is just a public-key distribution method. (That applies to Shibboleth at least; other implementations may disagree.) This does of course assume that you have a means of safely keeping metadata for the other end of the trust relationship up to date. In an eduGAIN/local federation setting, that's easy enough to do with signed XML metadata feeds and daily fetches, but far less so for bilateral trust.
The XMLDSig stuff is definitely a mess though. There were definitely issues with comments in signed content allowing values to be truncated to the start of the comment, along with some similar weirdness with XML entities. And that's before any of your (entirely valid!) complaints...
Oidc middlewares already exist. Many authentication providers/software call it "federated login" or "social login" where they can delegate the credentials to a third party if so configured.
Maybe clarify what you can do better or different or just how exactly you're doing it and let the audience decide.
While designed to accommodate many use-cases (which ist Not a bad thing), I'm curious what you seem overly complex? They're both pretty straight forward (except for single logout in SAML, which was never truly resolved and just left to die)
One advantage of SAML over OIDC - they standardized IDP initiated login, so you can skip the "login using..." button when sending an already logged in user to a third party system.
But the various XML canonicalization specs, XML transforms, embedding X509 certificates, all the mess they created to be able to embed signatures inside XML messages instead of just sending them separate from the assertions, is horrible to get right and will be a source of more security bugs for many, many years to come. https://www.google.com/search?q=canonicalization+CVE+SAML
> One advantage of SAML over OIDC - they standardized IDP initiated login, so you can skip the "login using..." button when sending an already logged in user to a third party system.
Having worked with implementing SAML for a large University-funded application, I learned more than I ever wanted to know but less than I needed to know
This is exactly how it works every time I need to touch SAML. Spend two weeks with the ping identity manual, somehow get everything working, forget all about it until the next time a customer wants it :}
Ping ID is "SAML" - they actually don't comply with the spec. If you remove the Bearer element from the SAMLRequest, you should be on your way. Ask me how I know.
I see this comment often, but when I implemented SAML, the spec wasn't too unreadable... I did write my own IdP [0] instead of using something that existed though, since those were more complicated than I needed.
So maybe because I only implemented features I was using it wasn't bad. What did you struggle with?
When I tried to do this, I was looking at an OASIS spec I think? Several hundred pages? I found it to be quite impenetrable. Mainly because of all the jargon. It was all defined of course, but just in terms of other jargon. It was a bit like trying to understand monads by reading wikipedia. In the end I spent about a month on the project, with basically nothing to show for it. If GPT had existed at the time, I probably could have gotten enough of a foothold using AI conversations to understand the spec.
I was in charge of a SaaS offering for Academic and Public libraries years ago, and we had to add SAML functionality for the Academic side ... it was a frustrating few weeks, and I was glad when it was over.
A minor mistake: You say "An identity provider (ISP): the centralized service your user will use to authenticate". You mean "IDP", not "ISP".
(That happens to me w/ using uncommon initialisms that are one letter off from the ones I use more commonly. My muscle memory inevitably makes me type some fraction of the more common one even when I mean otherwise.)
When I had to figure out how to add SAML authentication to a custom application, I built a barebones, no-framework Java application[1] just to understand the webflow. A good way to understand it is to just set up your own IDP like Keycloak running locally and play around with it.
I still can't find a convincing reason to use SAML over OIDC.
To me the SAML vs OIDC difference looks (also for the exchange format) pretty similar to the situations where XML vs JSON is used.
That is, I've always seen SAML as being very old / enterprise, and OIDC being the breath of fresh air that is JSON compared to XML.
I'd love to be proven wrong and start seeing SAML under a different lens as I don't currently see any benefit in starting a new project thst supports SAML
> Just speaking practically, the biggest reason to support SAML is that customers use it.
This is a huge reason to support SAML, I agree. You can talk all day long about how OIDC is better, but if a customer or application only supports SAML, that's what needs to be implemented.
Especially since single sign-on is usually an enabler, not the whole value proposition of any application.
Not even close. Pretty much every enterprise uses it because, from an admin point of view, it does everything the customer wants. Centralised user management is pretty much mandatory for different compliance and AD and Okta meet those needs just fine.
Hell, from a user perspective, I don’t even hate the Okta SAML implementation now we have support for Yubikey enabled. Click a button, I’m in.
The beauty of this spec is that it defines a set of basic components to build multilateral federations between various types of entities (without a need to rely on Web PKI + of course, the types of these entities are limited by the imagination only). Regardless of what's going to happen and what isn't going to happen to existing SAML multilateral federations, I think this this specification might begin to be adopted for various other use cases.
It's worth mentioning, the spec was also written by people who aren't new to anything from that, they were already deeply involved in SAML multilateral federations.
Saw some simplifications in the post like where the signature goes (it can go in the assertion but also can go in the response) but appreciate this is a gentle intro, as the author states:
> I’ve omitted a lot of details here, some of which matter greatly for security reasons.
One thing about SAML is that, like HTML, the world is the best test case, and you can run into compatibility issues over and over (hyrums law and all that). My employer, FusionAuth, also supports SAML and has for years (first commit to our open source SAML bindings was in 2019) and there are still edge cases we run into.
Having dealt with the operational side of SAML implementations, as well as implementation of the spec, it would be nice if tools like this generated docs for customer setup that are app specific. This would go from initial setup to certificate updates to configuring custom attributes supported by the SP.
"SAML isn't a recipient for innovations" or something along this line was once said by Vittorio Bertocci... it's hard to add much to it.
OpenID Connect is a core for many new specs in the space, "OpenID for Verifiable Presentations" and "OpenID for Verifiable Credentials" just to name a few.
Any new company choosing one vs another, I suggest to take into account this aspect.
I'm glad this company is building an open-source and straightforward solution for SAML integration. I struggled to find the right solution for my product and tried multiple libraries and services, including AWS Cognito.
Diving deep into OAuth and OIDC was crucial. Lesson learned: stick to the basics.
Sure! I think Cognito is a decent solution. However, client-app integration can be tricky, and the documentation is quite ambiguous in my opinion. The recommended implementation option is Amplify, but I had concerns because it doesn't support HTTP-only cookies.
I also experimented with NextAuth.js, but its documentation wasn't great, possibly because they're working on a new major version. I struggled particularly with supporting multi-tenancy with Microsoft AD.
I noticed that you offer SAML over OAuth. I'm curious to try that out.
Yeah, we made SAML over OAuth available mainly for ease of use in NextJS. Drop me a note (email in HN bio)if you end up trying us out. Would love to see whether we're on the right track.
Unfortunately it’s hard to get JUST the 1.0 spec anymore And 2/3 weren’t really my cup of tea… but it’s still simpler and the basics (of honestly all these systems) is the same
I particularly like the idea of "modes" which discusses different ways of thinking about authentication and authorization based on who holds user data.
