I'm trying to design a secure RESTful API web service with as few moving parts as possible. I have some questions, and want to make sure my design is secure.
For the data transmission level of security, I'm going to use SSL/TLS to prevent interception, MITM, replay attacks, etc.
What that leaves is access control.
I have no desire to fight with OAuth. The reason being, I do not want to rely on a third party, and setting up local servers as the "authenticator" (or whatever OAuth calls it) isn't feasible.
So I was going to rely on a random token. Using a CSPRNG library (e.g.,
$token = random_bytes(32) in PHP), I plan to assign each username/password a
$token, and store it in the DB using a password storage function (e.g., PBKDF2 or bcrypt). The token would also be retrieved by the user via SSL/TLS.
Then, on each request, the user will submit the token along with their JSON data. If the token they pass exists in the DB, the API call is processed.
This leaves me with quite a few questions:
- Can the token stay consistent (short of revocation or manual refresh), or should the token require being "refreshed" frequently? If so, what is the feasible way to handle that? Forcing the user to log into a web page to gain access to the new token seems to defeat the purpose of an API. This seems to indicate that it's at best a controversial point.
- What is the advantage of putting the token in an HTTP header (e.g.,
Authorization: Token SOMERANDOMVALUE) versus just stuffing it in the body of a JSON request? Either way, I'm not going to do anything with the request unless authentication succeeded. I was going to put it in the header anyway, but I was just curious.
Also, if anyone has any trustworthy sources to learn more about building secure API's, I'd really like to read them.