> Mutual-Auth SSL/TLS is a royal PITA, and is basically guaranteed to cause you grief. The client compatibility matrix might as well be considered an NP hard problem to assure yourself coverage, and failure modes of the different browsers/SDKs all differ. As a REST API should have maximum accessibility to clients (i.e., don't wed yourself to any one language/sdk), this is pretty much a non-starter.
Given the inconsistent support for mutual-auth TLS, which along with its direct ancestors has existed for a decade and a half, what makes you think they'll be widespread and correct support for SAS?
If by SAS you mean SSH, then really it's that there's a much smaller client surface area (really, openssh), and the fallback is always "use a PKCS#8 private key", which is much more uniform than SSL. SSL mixes in x509, and protocol, and UX.
That said, you don't have to agree with it. My macro point was really assessing these things against basic security threat modeling, not whether or not you agree with our choices of using SSH.
Well it's more than SSH. The client library needs to to implement the headers and do the date signing. Sure it's easier than TLS, but the libraries suffers more from a lack of dedicated interest than insane complexity I would think.
But I do agree with your basic point that too many people stop at authentication, instead of considering the full range of concerns.