Recently I have been exploring how to offload authentication to an identity provider via SAML. I wanted to augment my apps and services to become service providers. While researching the topic I found resources that advice about the perils of SAML. The great apenwarr captured it very eloquently :
It’s similar to IPSec in this way: theoretically fine if implemented correctly, but very prone to serious implementation mistakes
There are two reasons why SAML is difficult to get right. First, it uses XML, which is "hard to form, hard to read, and hard to parse". Second, the specification is complex. All these lead to bugs, high maintenance cost, edge cases and a high number of possible attack vectors.
In this post, the folks at workOS claim that most of the bugs come from the Service Provider (SP). They argue that SSO is typically not the core functionality the service provides, so developers rush into implementing it and they may not properly verify the assertions from the IDP.
I wanted to make easy for people to enable SSO via SAML on their applications and services. For that reason I wrote caddy-saml-sso, a Caddy module that uses this Golang library (implements all the SP bits). I think the module improves dramatically the ergonomics of deploying a SAML SP. Let me know if you try it and have feedback.
To me, the take home message is: try to avoid SAML. And if you can't, make sure you use a library you trust. And maybe, take a look to caddy-saml-sso.