Sounds like SAML needs the same "everyone gets together to make a FOSS implementation that knows about the weird quirks of all the implementations it interacts with" approach that e.g. the Samba project was founded upon.
I agree. There's a million SAML for Java/Python/Node.js/Foo libraries out there, all with a long list of issues and known cases that don't work correctly, security issues etc. but it's the wrong model in my opinion.
Instead of directly bolting SAML into your app, I think a FOSS implementation of an independently running service is the way to go. You run the battle tested open source service (locally / in your cloud), it accepts the SAML assertions and mints something sane like JWTs which can easily be consumed by the service providers, isolating the entire thing from your core app and allowing it be used with any stack. E.g. essentially an open source locally deployed Okta. Doesn't even need to do any user management, just focus on rock solid interoperability and forward all decision making to the actual app server.
If you want JWT tokens, you should be using OpenID Connect instead of SAML. There is very little reasons to use SAML in 2020, it's over complicated and has little support. OpenID Connect does 95% of the same, much better.
If you want self hosted IAM solutions. The most common one is Microsoft active directory. It provides both SAML and OpenID Connect integrations out of the box as of ADFS 2016.
Still, SAML requires to onboard applications individually, create keys, and stuff. It's not plug and play, it really needs humans on both sides to add a new service.
Unfortunately the demand for SAML is 100% customer driven. As service providers, we don't control the other end (the customer's IdP/AD).
Even in cases where the IdP supports both SAML & OIDC, I see almost no one choosing to use OIDC (a case of the devil you know?). The only real users of OIDC in an enterprise setting I see as a service provider, is G Suite businesses.
I think this is mostly driven by history. OIDC came in few years after SAML, so people are still thinking of SAML first and asking for it for enterprise integrations.
I'm pretty sure OIDC can be supported everywhere now. Okta, Oauth, PingIdentity, ForgeRock, Microsoft all support both. The last offender was Microsoft but it's included with active directory since 2016 both on premise or through Azure.
I'm working on auth for a big bank and it's definitely there, although not necessarily advertised and not everybody understand what is supported or preferred.
If a company were to only support OIDC nowadays, and maintain that OIDC is the preferred protocol when customers ask "can you do SAML?", I am willing to bet that most customers would integrate just fine either way.
> it accepts the SAML assertions and mints something sane like JWTs which can easily be consumed by the service providers, isolating the entire thing from your core app and allowing it be used with any stack. E.g. essentially an open source locally deployed Okta
This sounds like Shibboleth. The SP bolts onto httpd and delivers things like user attributes as server variables that apps can simply read. It even works if httpd is a reverse proxy in front of nodejs or whatever else, since you protect the app using location directives which play nice with proxypass directives.
The opposite certainly exists though, for example simplesamlphp which gets commingled into a php app codebase as you described.
