I have some web sites programmed, I know to do it with python and PHP basically. Normally they are simple web sites, but now I want to provide REST web services but only for allowed users (allowed by me).
I saw that a lot of services uses the “KEY” and “SECRET_KEY” concepts, which seems to be what I need (if I understand it right).
My suppositions are:
- If I only do a GET service to retrieve, e.g., all my clients, without anymore, anyone can retrieve my clients without limitations.
- I will need some KEY generator to provide keys for my allowed users, so they can use my webservices.
- Only with a KEY is not enough: someone can steal a KEY and supplant my user (and this is the reason because exists a SECRET_KEY, right?).
If all this is right, how can I make/use a system like that in my web services? Some open source example?
Or maybe there are another easy solutions I’m not considering?
My objective is to allow some users to use my web services.
4
The solution is relatively straightforward, once you have understood it. The very basic explanation goes as this:
You have a client and a server. The client has a private key (or secret key). The server can retrieve the private key from a database based on the public key of the client. If the client now sends a request to the server, it calculates an HMAC hash from all the parameters that it would send anyway plus some extra goodies. These extra goodies are the private key, a timestamp and nonce value.
The server receives the request with the hash and recalculates the HMAC hash to verify that the real client sent the request. Since the private key can be received from database, no vulnerable data is transmitted via Internet.
The timestamp and nonce prevents man-in-the-middle attacks that try to replay the message. Such an attacker would either need to include the real nonce and timestamp value or a modified one. With the modified one, the HMAC hash won’t fit and with the original one, the server can recognize that a request with the same values has been uttered already.
In short this is the explanation for the procedure. It is comparable to the two-legged OAuth.