That’s never the case though - you don’t just “turn on” SAML integration. It’s a huge support burden, with every SAML provider requiring unique (and frequently

That’s never the case though - you don’t just “turn on” SAML integration. It’s a huge support burden, with every SAML provider requiring unique (and frequently updated) documentation, testing, and support enablement. And that’s assuming you don’t include auth in any of your release testing cycles (which you should). If you do, now you’re including unit and end to end testing with Okta, MS, Google, OneLogin, Jumpcloud, Ping, and anyone else your customers choose to use. Don’t forget to run those tests with both SAML and OIDC. And make sure the engineers who know how to co figure each of those vendors’ SSO systems are aligned with your testing schedules. Also don’t forget that you need dev/partner accounts with all of those vendors. And they’ll need to be active when you test.