| > - Do you support SAML 2.0 clients? There be dragons. (Disclosure: I work for FusionAuth.) Funny story. We had a client doing a SAML integration using HTTP-redirect bindings. It worked when you turned off request signature verification (which is fine for testing, but is like using alg="none" for JWTs, a non-starter in production), but failed when that was turned on. We dug in with the client and another vendor, set up some test servers, and identified the bug[0]. Turns out that you can't canonicalize the signature's URL encoded form, because both uppercase and lowercase hex values are allowed, by the SAML spec. Our open source SAML library[1] has been around for years and used by many clients in FusionAuth and our other projects. It'd never run into this particular edge case. It is a wild west out there in SAML land and it takes years to build a bulletproof implementation. Ory folks, if you can leverage an existing implementation rather than rolling your own, I'd highly advise that approach. That is also to say nothing of the incoming privacy/cookie limitation changes that are coming in the next few years. This will unfortunately probably negatively affect SAML, which is not a specification that has evolved much. If this is of interest to you, I'd recommend the Federated Identity W3C community group[2]. That said, FusionAuth supports SAML in many forms[3]. SAML support varies across vendors and implementations, but other providers like Keycloak and IdentityServer do so as well. 0: https://github.com/FusionAuth/fusionauth-issues/issues/1496 1: https://github.com/FusionAuth/fusionauth-samlv2 2: https://www.w3.org/community/fed-id/ 3: https://fusionauth.io/docs/v1/tech/core-concepts/integration... |