Earlier quoted context omitted.
No. The UA strips those and puts them in an Auth header.
Depends on the UA (curl?)
Even curl does the right thing for basic auth
Secure Your REST API
71–80 of 80 posts
Re: Secure Your REST API
#72You should probably disregard this advice. Instead: [Late addition: * 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) w…
So let's say I have an iOS or Android app that needs to talk to my REST API. I have my user login in the app, which does Basic Auth over HTTPS. Once they're authenticated, I generate a token and send it to them. They store it, and use that token from here on out (HTTPS only). Perhaps I expire it after some time (hours or days, if I don't want my user to have to login all the time). That's it? :D Seems like I'm missin…
That sounds good. Think about how, e.g., Gmail lets you persist sessions on each device. They're doing a password auth over HTTPS and leaving a cookie with some session token.
Re: Secure Your REST API
#73You should probably disregard this advice. Instead: [Late addition: * 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) w…
Do you think there would be value in accepting HTTP requests and then automatically and immediately expiring every credential that ever gets passed over plain HTTP ?
[deleted]
Re: Secure Your REST API
#74You should probably disregard this advice. Instead: [Late addition: * 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) w…
Do you think there would be value in accepting HTTP requests and then automatically and immediately expiring every credential that ever gets passed over plain HTTP ?
With an API, I think you're better off just not accepting HTTP connections to begin with. This is library design, so, principle of least astonishment. Break hard and fast.
Re: Secure Your REST API
#75You should probably disregard this advice. Instead: [Late addition: * 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) w…
So let's say I have an iOS or Android app that needs to talk to my REST API. I have my user login in the app, which does Basic Auth over HTTPS. Once they're authenticated, I generate a token and send it to them. They store it, and use that token from here on out (HTTPS only). Perhaps I expire it after some time (hours or days, if I don't want my user to have to login all the time). That's it? :D Seems like I'm missin…
That sounds very close to OAuth 2.
Re: Secure Your REST API
#76Earlier quoted context omitted.
The user interface in browsers for client certificates is appalling. The API support in client SSL libraries for managing multiple certificates, for applications with multiple API affiliations, is shaky. I like TLS client authentication a lot, but it's hard to make it work.
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 cas…
Look at the OpenSSL libraries for php regarding certificates. Its very close to unusable, you cannot get or set some pretty basic information like SANs.
Re: Secure Your REST API
#77Earlier quoted context omitted.
Depends on the UA (curl?)
OK, so it'll either add an auth header or not know what to do and refuse to do anything. Either way the password is not sent in the request url
Actually, I mused have screwed up last night. The version of curl I have does support it and does put it into the Auth header.
% curl --trace-ascii /dev/stdout http://jimktrains:password@news.ycombinator.com
== Info: About to connect() to news.ycombinator.com port 80 (#0)
== Info: Trying 184.172.10.74... == Info: connected
== Info: Server auth using Basic with user 'jimktrains'
=> Send header, 223 bytes (0xdf)
0000: GET / HTTP/1.1
0010: Authorization: Basic amlta3RyYWluczpwYXNzd29yZA==
.......
Re: Secure Your REST API
#78Earlier quoted context omitted.
Even if you use HTTPS, aren't you vulnerable to lazy devs who put the password in the URL? If I use https://username:password@example.com/ , doesn't that URL show up in server logs all over the internet?
Don't ever use passwords for API authentication. It's an API, not a browser. The users of an API are other programs, not people. Issue single-purpose random credentials. I didn't think this was something I had to point out about API authentication, but apparently it is.
By "don't ever use passwords" you mean, "don't let users set their own passwords," right?
Obviously, you're still using a password if you use HTTP Basic Auth.
Re: Secure Your REST API
#79Earlier quoted context omitted.
Even if you use HTTPS, aren't you vulnerable to lazy devs who put the password in the URL? If I use https://username:password@example.com/ , doesn't that URL show up in server logs all over the internet?
Don't ever use passwords for API authentication. It's an API, not a browser. The users of an API are other programs, not people. Issue single-purpose random credentials. I didn't think this was something I had to point out about API authentication, but apparently it is.
[deleted]
Re: Secure Your REST API
#80How does using bare api keys over TLS compare to these suggestions? It's less secure but is it still a recommended option?
The advantage to OAuth over basic-auth is that you can delegate the credentials, which is to say you can set up your system so that users can give a limited-use credential to a 3rd party application to perform API calls on their behalf. Some very large services have abused OAuth to "delegate" credentials to mobile devices, which has set up the expectation among developers that OAuth is the "sophisticated" way of doin…
[deleted]