If an app is a SAML SP or an OAuth client, then it's not really doing authentication itself, but rather delegating it to another system. When you go to log in to the SAML IdP or the OAuth authorization server, where the authentication actually happens, don't they let you use HTTP basic authentication or <input type="password">?
To get back to the main point, though, don't you think that the fact that Microsoft includes a disclaimer (kinda) in their docs lends some credence to the idea that they're not really proud of this?
Whether it's unfair to single out SQL Server -- I don't think it is. SQL Server is one of the foundations of modern IT infrastructure, and it should be held to the highest standard. This is clearly a chink in the armor, and Microsoft seems to be aware of it.
Thanks to your pushback, I have refined my argument and will publish a significantly revised version of it on SQL Server Central (https://www.sqlservercentral.com/) on March 2. There is a preview at https://www.galliumdata.com/articles/can-we-please-stop-send... in case you're curious.
I respect your expertise, and I appreciate your civility. Thank you.
Absolutely, but I am arguing that this is not worthy of an enterprise system like SQL Server. This is especially true for a back-end system, because at least in a web browser, you'd get a warning if the certificate cannot be verified (and the connection is therefore vulnerable).
> Which ones are you thinking of?
Most of the enterprise apps I have worked with use something like OAuth or SAML. For sure, many have an option to use basic auth, but that's only used for testing and development, and would be a red flag in any security audit.
I'll just quote Microsoft's documentation <https://docs.microsoft.com/en-us/sql/relational-databases/se...>:
It's good that they acknowledge it, but it would be a lot better if they did something about it.