3 ms·

I like HTTP APIs that use basic auth over SSL. Why? Because as the blogpost demonstrates nicely, curl is a wonderful tool to test, demo and debug things. As so

by rb2k_ 14y ago

I like HTTP APIs that use basic auth over SSL. Why? Because as the blogpost demonstrates nicely, curl is a wonderful tool to test, demo and debug things. As soon as you introduce e.g. MACs to the mix, you can forget about most unix-y commandline tools. I think we can all agree that there are better options when it comes to authentication, but I'd rather have something I can work with easily than worry about that tiny amount of possible "plain http pre redirect" mistakes. What about using http digest auth as a middle ground? It's still curl compatible and a tiny bit more secure.

hrrsn 14y ago
I agree, things like Oauth are also massively overkill for what should be simple jobs. The other day I was writing a script for my own personal use that needed to get some metadata from Imgur. Their API /requires/ OAuth, when even a json snippet for a public picture would have been just fine. Ended up just scraping the page as it was a one off script and was much faster than signing up, creating an application, implementing a library, etc.
- sgt 14y ago
  You can use a subset of OAuth - I tend to use the so called "0-leg" version of OAuth, which is pretty much the same as a username/password (consumer key + secret), but with added benefits such as protection against replay attacks. It's also pretty simple to implement on client side and server side. I usually give our clients a little library to get started with requests.
  - pifflesnort 14y ago
    I've implemented OAuth client-side a few times in a few languages. The signing process itself may not be that difficult to understand, but there are a lot of fiddly moving pieces, the specs are painful to read, and everyone has their own unique take on the spec. I wouldn't call it simple. It's complex to get right, and outright damaging to non-web clients except in the case where xAuth or similar is available.
  - tomjen3 14y ago
    Honestly there is nothing simple about OAuth -- and the specs are horrible (even when you understand them).
jamescun 14y ago
While if you are just implementing Key/Token auth for an API, Digest might be `good enough` but does not escape the problems associated with Digest, such as its reliance on MD5 (broken, if your token is complex and longer than 32 chars it renders it less secure) and the requirement to store tokens in plain-text[1]. If you are implementing username/password, then Digest removes the ability to use a secure password system like Bcrypt or PBKDF2, which is a killer. [1] You are able to store the digested tokens/passwords rather than plain-text, but if you need to protect the token/password in any way, the digest is an insecure way to do so.
quesera 14y ago
> As soon as you introduce e.g. MACs to the mix, you can forget about most unix-y commandline tools. I'm tempted to ask which command line tools you are missing in OSX, but I'm wondering if your capitalization was intentional and correct. :) If the latter, I've found that 10-line ruby "clients" can go a long way toward simplifying API testing.
- rb2k_ 14y ago
  I was talking about Message Authentication Codes rather than the Macintosh line of computers :)

by rb2k_ 14y ago

hrrsn 14y ago

I agree, things like Oauth are also massively overkill for what should be simple jobs. The other day I was writing a script for my own personal use that needed to get some metadata from Imgur. Their API /requires/ OAuth, when even a json snippet for a public picture would have been just fine. Ended up just scraping the page as it was a one off script and was much faster than signing up, creating an application, implementing a library, etc.

sgt 14y ago
You can use a subset of OAuth - I tend to use the so called "0-leg" version of OAuth, which is pretty much the same as a username/password (consumer key + secret), but with added benefits such as protection against replay attacks. It's also pretty simple to implement on client side and server side. I usually give our clients a little library to get started with requests.
- pifflesnort 14y ago
  I've implemented OAuth client-side a few times in a few languages. The signing process itself may not be that difficult to understand, but there are a lot of fiddly moving pieces, the specs are painful to read, and everyone has their own unique take on the spec. I wouldn't call it simple. It's complex to get right, and outright damaging to non-web clients except in the case where xAuth or similar is available.
- tomjen3 14y ago
  Honestly there is nothing simple about OAuth -- and the specs are horrible (even when you understand them).

jamescun 14y ago

While if you are just implementing Key/Token auth for an API, Digest might be `good enough` but does not escape the problems associated with Digest, such as its reliance on MD5 (broken, if your token is complex and longer than 32 chars it renders it less secure) and the requirement to store tokens in plain-text[1]. If you are implementing username/password, then Digest removes the ability to use a secure password system like Bcrypt or PBKDF2, which is a killer. [1] You are able to store the digested tokens/passwords rather than plain-text, but if you need to protect the token/password in any way, the digest is an insecure way to do so.

quesera 14y ago

> As soon as you introduce e.g. MACs to the mix, you can forget about most unix-y commandline tools. I'm tempted to ask which command line tools you are missing in OSX, but I'm wondering if your capitalization was intentional and correct. :) If the latter, I've found that 10-line ruby "clients" can go a long way toward simplifying API testing.

rb2k_ 14y ago
I was talking about Message Authentication Codes rather than the Macintosh line of computers :)