If the customer is using an identity provider like Microsoft Entra, is there any reason not to just use OIDC instead of SAML?
SAML: A Technical Primer
21–30 of 100 posts
Re: SAML: A Technical Primer
#22If the customer is using an identity provider like Microsoft Entra, is there any reason not to just use OIDC instead of SAML?
No. If you can use OIDC, you should do so; in fact, if you can't use OIDC, you should consider rearchitecting so that you can. SAML is that bad.
Re: SAML: A Technical Primer
#23This is a very weird page, as it seems to suggest that SAML is the only way to do single sign-on integration with IdPs like Okta. But modern systems all do OIDC, which is what you should do. You need a much better reason to support SAML than "the CISO wants it so they can use Okta", because the CISO can (and should) just use OIDC.
Re: SAML: A Technical Primer
#24If the customer is using an identity provider like Microsoft Entra, is there any reason not to just use OIDC instead of SAML?
No. If you can use OIDC, you should do so; in fact, if you can't use OIDC, you should consider rearchitecting so that you can. SAML is that bad.
That was my understanding and also my plan, but it does not seem feasible to force this as the vendor of the software. If the customer says they need SAML at some point the business side will require that it is implemented. I do want to try and get as far with only OIDC as possible, but I am a bit worried that some larger customer might just bulldoze through because they only want SAML. Might be much more likely for on premise cases, if you're in the cloud you probably use an identity provider that supports OIDC already.
Re: SAML: A Technical Primer
#25Earlier quoted context omitted.
No. If you can use OIDC, you should do so; in fact, if you can't use OIDC, you should consider rearchitecting so that you can. SAML is that bad.
That was my understanding and also my plan, but it does not seem feasible to force this as the vendor of the software. If the customer says they need SAML at some point the business side will require that it is implemented. I do want to try and get as far with only OIDC as possible, but I am a bit worried that some larger customer might just bulldoze through because they only want SAML. Might be much more likely for…
Yeah, SAML will probably fade away (slowly). And sometimes, you might be able to convince the customer just to use OIDC.
But human behavior change is hard and expensive. For the most part, it's just easier to give the customer what they're asking for / what they expect, even when you know they're wrong.
When you're trying to push an enterprise deal over the finish line, this is often just not a good enough reason to introduce friction with your buying committee.
And if you have to support SAML for one stubborn customer eventually, you might as well support SAML for all customers that really want it.
Re: SAML: A Technical Primer
#26Earlier quoted context omitted.
No. If you can use OIDC, you should do so; in fact, if you can't use OIDC, you should consider rearchitecting so that you can. SAML is that bad.
That was my understanding and also my plan, but it does not seem feasible to force this as the vendor of the software. If the customer says they need SAML at some point the business side will require that it is implemented. I do want to try and get as far with only OIDC as possible, but I am a bit worried that some larger customer might just bulldoze through because they only want SAML. Might be much more likely for…
We've managed to hold the line on OIDC so far. So has Tailscale. If Tailscale can hold the line, given who they're selling to, I think most orgs can. Really, try to avoid doing SAML. Remember, as a vendor, you're often competing with companies that don't do real SSO integration at all.
At the very least: if I was ever to do SAML, I would rip your face off in the pricing for it.
Re: SAML: A Technical Primer
#27Earlier quoted context omitted.
Oh, I thought it stood for: "Suffering A Massive Lot" - jk Let's just say my interaction with managing websites that used SAML was less than pleasant.
> Let's just say my interaction with managing websites that used SAML was less than pleasant. My interactions supporting it as both the identity provider & the service provider have lead to me being the SAML person at work, and I'm now very used to people either laughing at my misfortune or giving me pitiful looks. It combines all the wonderful antipatterns you can name: a protocol where near everything is optional a…
Do you renew the certificates used to distribute the public keys in SAML metadata, and if so why do you do it? I have had a hard time convincing people it is useless to renew those certs and have yet to find an implementation that care about those certificates.
Re: SAML: A Technical Primer
#28Earlier quoted context omitted.
That was my understanding and also my plan, but it does not seem feasible to force this as the vendor of the software. If the customer says they need SAML at some point the business side will require that it is implemented. I do want to try and get as far with only OIDC as possible, but I am a bit worried that some larger customer might just bulldoze through because they only want SAML. Might be much more likely for…
We've managed to hold the line on OIDC so far. So has Tailscale. If Tailscale can hold the line, given who they're selling to, I think most orgs can. Really, try to avoid doing SAML. Remember, as a vendor, you're often competing with companies that don't do real SSO integration at all. At the very least: if I was ever to do SAML, I would rip your face off in the pricing for it.
Lol, yeah, having SAML means putting XML parsing into critical security points. No thanks.
Re: SAML: A Technical Primer
#29Earlier quoted context omitted.
We've managed to hold the line on OIDC so far. So has Tailscale. If Tailscale can hold the line, given who they're selling to, I think most orgs can. Really, try to avoid doing SAML. Remember, as a vendor, you're often competing with companies that don't do real SSO integration at all. At the very least: if I was ever to do SAML, I would rip your face off in the pricing for it.
Lol, yeah, having SAML means putting XML parsing into critical security points. No thanks.
Even better: XML signatures, which are very easy to get wrong in both signing and verification.
Re: SAML: A Technical Primer
#30Earlier quoted context omitted.
No. If you can use OIDC, you should do so; in fact, if you can't use OIDC, you should consider rearchitecting so that you can. SAML is that bad.
That was my understanding and also my plan, but it does not seem feasible to force this as the vendor of the software. If the customer says they need SAML at some point the business side will require that it is implemented. I do want to try and get as far with only OIDC as possible, but I am a bit worried that some larger customer might just bulldoze through because they only want SAML. Might be much more likely for…
Microsoft Entra having first class support for OIDC really helps; I remember seeing a decision diagram in their documentation recommending using OIDC for new projects, it can help negotiating. Google Workspace also works just fine with OIDC, and so does Okta.
I've been told that the only source of problems is going to be companies using Shibboleth, even though there seems to be an OIDC plugin.