Ask HN: Best way to design an API authentication mechanism?

I'm designing a new API and use some insight and understanding about how best to authenticate callers to an API. For my use case, almost all calls will be from automated, non-interactive systems while perhaps 1% of calls will be from users in a browser. From industry as well as academic papers, here are the styles that I've seen thus far:

- Username/password provided in the clear (whether or not they use TLS to secure the channel) - Generated token provided in the clear (whether or not they use TLS to secure the channel) - A token with two parts: public and private where a signature is generated from the contents of the HTTP request, e.g. URL, request method, HTTP headers, etc.

Furthermore, I've seen the above values located in various places on the HTTP request:

- The "userinfo" portion of the request - In one or more query string parameters - The Authorization HTTP header - Various other custom headers, e.g. X-Authentication, X-Api-Key, etc.

A lot of the academic guidance I've seen points to signed requests with the signature populated in the Authorization header as being the most secure and canonical location for the authentication information. The trouble is that, except in a few cases, "industry guidance" (e.g. the API specifications of major industry players) does not follow the academic findings. Industry players typically will use a generated token sent in the clear in the query string or in the Authorization header.

It appears that the main concern around providing a signature-based approach is a decreased adoption of an API. This style appears to significantly increase the barrier to entry for using a given API. Wouldn't providing language-specific SDKs or at least sample code in multiple languages reduce or eliminate this concern?

I'm definitely not interested in inventing some weird, custom authentication scheme, but I am curious to hear everyone's thoughts on this.