I expected something very different from this article based on the headline. Specifically, I completely disagree with the "leave it to industry standards" approach, as that doesn't help people understand what they should do, and more importantly, why.
Request/response protocols (well, many things) really break down into 5 top-level categories (some sources will say the 6th is Audit):
- Authentication
- Authorization
- Integrity
- Confidentiality
- Non-repudiation
It's a far more interesting exercise to walk through what you would get from each solution. Basic-Auth over TLS, actually gets you quite a ways towards that goal (specifically, C-I-A (authentication)). Where that, and notably HMAC, fall over is non-repudiation because they're based on a shared-secret model; admittedly HMAC keys are better than passwords because you're not sending the secret on every request, but asymmetric crypto is preferred. Authorization that the
server system does is really out of scope in all of these protocols, so Basic-Auth over TLS doesn't really impact that one. It can be as simple as "caller = owner," or as full-featured as a security policy language [1] (full disclosure: I am the original author of [1]).
OAuth really doesn't differ that much besides specifically solving the delegated access and website SSO problem(s); but IMO it does so with an overly baroque protocol that has too many parts. The "long pole" of setting up such a system (that is, allowing 3rd party sites to act on behalf of my site's users) isn't the specifics of what my REST api
looks like, but really it's all the "governance" of user decisions, and more-over, key management (in all these cases, key management is generally the hardest or almost hardest problem).
While it can be debated whether it was right or wrong, we (Joyent) released an open-source spec to solve straight up authentication of REST requests using SSH keys [2]. At the end of the day, the user signs the Date header of requests with their private key (which by definition the server has never seen), and all requests must be over TLS. Disregarding Authorization, this scheme gives you Confidentiality (TLS), Integrity (TLS), Authentication (Signature), Non-Repudiation (asymmetric signature), and adds a "poor man's nonce,"
assuming you disallow requests where the clock skew of the date header is too large. And lastly, SSH solves a lot of key management problems for humans. Note: I didn't drop that reference to advocate for our specification here, but rather the security process you should think about when evaluating whether a protocol is secure.
[1] http://docs.aws.amazon.com/IAM/latest/UserGuide/policy-refer...
[2] https://github.com/joyent/node-http-signature/blob/master/ht...
PS
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.
* edited: copy/paste formatting