4 ms·
But if your clients include things that aren't browsers, HTTP Auth is the only acceptable choice.
by psadauskas 16y ago
But if your clients include things that aren't browsers, HTTP Auth is the only acceptable choice.
- tptacek 16y agoThat's not true either; you can just do what big API apps do and generate access tokens. Amazon Web Services don't rely on HTTP-Auth.
- psadauskas 16y agoUsing curl to access AWS is kind of a pain, since you have to hash the body and your keys into a header. For others, you have to set the token in a header, and it (should) change periodically. Compare to: curl --anyauth --user login:password https://example.com/
- tptacek 16y agoIt's a "1 line of Python" pain, true, but it's also significantly more secure. From a cost/benefit perspective, it's an API, a building block of a software development project, and optimizing it for curl-ability doesn't seem like a major win. But my point is just: HTTP Auth is not the best-practices answer to non-browser web services auth. Both API-key and signed URLs are both competitive (and probably better) options.
- mjw 16y agoWhat about for SSL-based APIs? it seems a pretty optimal choice for those.
- tptacek 16y agoI don't think it is, for two reasons: (1) For most large apps, you're not really SSL in the provider's own network, so there's always the cross-app risk if something horrible happens. (2) It's forcing app-to-app, business-to-business authentication into a username/password mold that doesn't many any real sense; a 128 bit random key (or an SSL client cert) makes more sense anyways. Against those two problems --- which are marginal, I concede --- HTTP Basic offers... exactly what advantage? I don't see it.