Securing a REST API and Slim Framework
I am fairly new to REST APIs, and I realize there are quite a few questions already posted. However, perusing these has actually left me more confused on how to handle this.
I have created a REST API using Slim Framework which I am simply using to transfer data. I won't be using user logins or authentication, so I believe to secure this I just need a system that using a public key and a private key, but I am just not sure.
If anyone has insight on the correct / most secure way to do this, or any tutorials / resources that would be great. Any help is appreciated.
Answer
You can use SSL to encrypt data in transit.
But SSL is just encryption; server-side ssl does not do authentication of the client, nor authorization. You can think of authorization as answering the question is the caller allowed to do what he is asking?. Authentication establishing the identity of the caller or Authentication is usually a necessary first step for doing authorization. Sometimes you don't need "the whole identity" - you just need to ascertain a particular aspect. For example, an automated washroom gate would not need to know who you were, but only if you were male or female in order to ascertain identity. In the same way, some services don't care who you are; they will allow access if you are calling from a particular network (ip whitelist) or if you carry a special token.
To allow the server to distinguish between authorized and unauthorized calls you have some options:
IP whitelist. If you know the IP address of the app or agent which will call your service, you can specify that in your service implementation. The service can check the IP of incoming requests and reject those that are not on the whitelist. This is sort of "implicit" authorization based on the caller's address.
a secret token, that the app provides in each call. You said you didn't want to do authentication, but this is a form of authentication. You might call it a "bearer token". Anyone who bears this token gets authorization. In your server you'd check the value of the token and reject any calls that don't match the well-known value. This works much like the IP whitelist except the token is explicitly passed, and does not have any relation to the network address.
a token + key pair. This is like a username / password, but it can be used to authenticate the app. Use this to provide the identity of the app itself. Check on the service side as above.
a username / password. To authenticate the user of the app.
You may want to combine these to produce the solution you want. In other words, the client request needs to be from the right I address, and needs to have a token/key for the app, and a username/password for the user, in order to be considered "authorized".