The Function of an API Key PHP / MYSQL

Question

A quick question about API Keys with PHP/MYSQL. I have been doing a lot of reading over the last few days but just need further clarification and some best practice guidelines as I am only very new with HTML, JS, JQUERY, PHP / MYSQL.

My server side code is PHP, which connects to the MYSQL database. The database has a users table which will store columns such as id, username, password (which uses password_hash() via PHP5 so it does not store the plaintext value) and api_key. I will also look at adding some such as last_seen and last_login for further security.

I would like the API Key to be used to authenticate the user to access resources on the server (eg. parseID.php, which takes POST arguments to return a JSON result on the ID's the user enters). The user can use this API key in a script as well to access the JSON output if required.

My thought process is:

• An already logged in user clicks a button to generate an API key.
• The script generates an API key (Using password_hash()) and saves it against the user ID in the database
• When a user wants to access a protected resource, they will provide the given API key in the GET/POST (or stored in a session??) which will attempt to match it with the one in the database and return the result (Auth VS Not Auth).
• If authenticated, The User is able to access the resource.

I will also use SSL to encrypt the traffic between the user / resource.

I am a little unclear and wondering what other steps / best practices can be taken here to ensure that the API key and the users information is safe?

All of the information I have searched on here and on google is a few years old and using practices such as MD5 to encrypt the keys.

Thanks!

Answer 1

This is correct - the API key is assigned to the user and calls are required to pass the API in order to authenticate the user and check what they can do.

Some changes I'd suggest:

An already logged in user clicks a button to generate an API key.

If the user can only have one API key, it will be easier for you and users to just generate the API key when the account is created and make it available in their profile/settings area (i.e. make it a one-to-one relationship rather than one-to-zero-or-one). The only reason you'd want to generate it on demand is if you have to give explicit permission, e.g. through some moderation process.

Either way, you will also want to let users reset the API key (mainly in case of a possible leak).

BTW a more common pattern is to support multiple API keys. e.g. if you look at Twitter's developer dashboard, a user can create N "apps" and each app automatically gets its own API key. There are some advantages to this approach, e.g. you can gather metadata around the apps, API keys are partitioned (better security), permissioning models can be different for each app, and you can revoke a single app without affecting all usages. All that may be overkill for you though.

stored in a session??

Session is more of a web concept related to cookies being passed back and forth. You don't need that complication. It should be easy enough just to require the API key in every request path.

When a user wants to access a protected resource

You may as well require the API key in every request, not just those for protected resources. It should be just as easy for the user anyway, and it will let you do things like rate-limit and log requests on a per-user basis.