You should probably disregard this advice. Instead:
* Do not use passwords as API authentication. The user of an API is a computer program, not a human. Issue single-purpose random credentials for API access.]
* Make sure that your API is accessible only over HTTPS; test the API endpoint to ensure requests aren't honored over unencrypted HTTP.
* Use the simplest API authentication mechanism that (a) works and (b) you understand. You should probably degrade the capabilities of your API before you try to adopt an authentication system that you don't completely, fully, absolutely grok.
This means, if you don't need delegation right away (for instance, if you don't have 3rd party applications making calls to your API on behalf of your users), don't bother with anything like OAuth.
Contrary to the implications in this article, HTTP Basic Auth is not less secure than OAuth if your endpoints all require HTTPS. If you allow HTTP calls to an API, you have bigger problems than your auth token scheme.
Semantic mismatches between API endpoints and web UI endpoints (ie, semantic differences between API auth and cookie-based authentication) are a classic, pervasive, hard- to- eradicate source of serious security flaws. Don't make things any more complicated than they need to be.
[Late edit: I didn't think I needed to make the first point, but I clearly did need to. Sorry.]
> Semantic mismatches between API endpoints and web UI endpoints (ie, semantic differences between API auth and cookie-based authentication) are a classic, pervasive, hard- to- eradicate source of serious security flaws. Don't make things any more complicated than they need to be.
Could you explain that one in more detail? I don't think I understand it.
The one true solution is client authenticated TLS. For the life of me I can't understand why 25 years later certificate management is still such a mess.
We don't need some perfect universally recognized root trust system to get started. Why doesn't the sign up process for authenticated API access routinely include the issuance of a certificate signed by the API owner?
Unlike for interactive users there's no expectation that a customer will be accessing an API from some random computer where he might not have access to his certificate store.
I agree it's awful to use, but what I don't understand is why no one has bothered to improve the tools.
It's one of those areas where the underlying tool (either a library like openssl or NSS, or an OS feature like SSPI) could do the hard work in one place and make it simple for downstream libraries to wrap the functionality.
In other, somewhat analogous, domains that happened, but for whatever reason not in this case.
Well, in this case (having gone back and actually checked the docs rather than relying on recollection roughly a decade old) you could store MD5(username:realm:password) rather than password, though that doesn't buy you all that much in a case like this where making the password a long, random string that's not reused is not only good practice but also easy and so likely to be general practice.