Before I start, I want to tell that I am new to building RESTful APIs and also have never dealt with any authentication.
I want to setup a main server which will get API requests from client (let the server IP/Domain be, api.example.com). I want to be able to use POST request to send a file to the server with an API key. What are the ways that I could authenticate the API key in the main server and then POST the file again from there to another server depending on the API key (like two categories 0 and 1)
If the file is publicly available on client server, is it good if I just send the url to the main server which passes it to the second server and then download the file there ? Once that is done, the client will also have to use a GET request.
I am thinking of having wordpress on main server to make registrations easy (write a plugin to generate api to each user). Is it a good idea ?
I have seen this : Web API creating API keys
But the client side will be public (all the client side services I will write will be open source and the api itself is open for developers to develop for their own need.) So I figured hashing the key with any method can be reversed because it's public. I just want to use a single API key around 30 characters and their email and match it in main server.
EDIT
I just figured out something, but i don't know if it's a good strategy. If I could ask the users to add the domain from which the will make the request, and then just have only one API key and send it to the server so the server could match between the APIKey and the Domain and if it is listed continue with the POST.
You can use HTTP Headers to implement your authentication. Typically users will base64 encode the AUTH Header containing the API key issued to them. The server application will decode this API key from the HTTP Request it receives and perform a lookup from a datasource to validate the keys.
Related
I have a mobile app that needs to use Api keys in order to make requests, I however don't want to have the API keys saved to the app.
I want to use Laravel as a sort of proxy so that I can catch the request, modify it with the API keys and any other info and forward the request downstream
Any leads on how to achieve this?
This is not a Laravel problem per-se. Consider this: when you store the APIkey somewhere in the protected storage of a mobile device, you are using an industry standard way to "secure" your secrets. If those secrets are in danger, the operating system would surely be patched.
If you inject the API key into an external web server, you are making the API key useless, since now all the incoming requests are not authenticated (you are not using an API key on your client since you are injecting it at server side).
Therefore, you are developing a public web server in which all of your resources are freely available and abusable, defeating the purpose of having an API key.
I have an iPhone app that is using my php api on the server but it is currently open if someone knows the url. I want to make sure that no one can use this API until I am ready to make it a public api (if I even do)
I have read this article but I am unsure what they mean when they say:
[CLIENT] Before making the REST API call, combine a bunch of unique data together (this is typically all the parameters and values you intend on sending, it is the “data” argument in the code snippets on AWS’s site)
I don't understand how if I hash the parameters I plan on sending with my api secret how this is more secure than just hashing the api secret if I send the parameters/values unencrypted.
HTTPS the API and use an API key. Then you'll know that only people (you in this case) with the key can have access to the API.
You're correct about it not being more secure. That's why I suggest you SSL the connection. Unless you plan on encrypting everything you transmit back and forth.
The public/private key scenario will also work well. HTTPS requires very minimal effort.
Digital signatures provide a way of validating a message sent over an insecure connection.
Setup: each client will have its own private key and public key (only the private key needs to be stored on the client). The server will store the public keys for each client. The public key can be visible to all and can be used by the server to identify the client. The private key, known only to the client, it is never shown to anyone.
The client signs the request: along with the rest of the request data, the client will hash the combined request data and encrypt the hash with the private key. The server will generate the hash the same way (leaving the signature out of the hash calculation), then decrypt the signature using the public key. If the hashes match, the request is authentic.
Note that HTTPS allows for client certificates, so you can leverage existing tools to accomplish all of the above without writing a single line of server-side code (you just have to configure your web server; the only trick is to make sure the server only accepts certificates it already has). Moreover, the amount of client side code should be minimal: you shouldn't need to do much more than set the connection to use the client certificate. Since you're controlling the clients, you can use self-signed certificates and add the server as a certificate authority. There are a number of questions on SO about using client certificates in iPhone apps; you can start by reading through them.
Note also that any scheme to protect the web API only works so long as copies of the app are in trusted hands. Should anyone untrustworthy get ahold of it, they can use the app or extract any secret data used by the app and access the API as they will.
For development purposes you can just use your web server settings to allow requests from your ip only.
I have a security-related question - I'm developing an app that populates its database by using a PHP script on a remote server. I wouldn't like to make the PHP script publicly available, but just use it from the specific mobile application (written with TypeScript using the Ionic Framework). How could I accomplish this?
Make your mobile application to provide with the query some kind of secret string / token. And your server side PHP script will not proceed without valid token provided from the request.
The token can be part of your POST/GET/HTTP header or so.
What I've done in the past to achieve something like this is to setup an API key system. You generate API keys server-side, and you lease out valid keys that you have generated to your application(s). You would then use that key in your application, and that would get sent to the server and parsed by a php script whenever you call the script from your mobile application. If the key is valid, then the request is valid.
There are some security considerations to think about, i.e what happens if someone gets your API key? Are you logging remote IP's (and fully qualified domain names) and API usage, will your system be able to invalidate the key whenever necessary? Is the API request utilising TLS connections?
I want use POST to Transfer data between PHP server and Android client, how to improve security? For example, how can you ensure that believable and successful access to the server API can only be my Android client?
because of app have Login mechanism, so I think I should add the account verification code in every post(It consists of user password and so on, may be encrypted by MD5), Then every POST have clear sources, if the source is invalid(don't have verification code or it's wrong), Server denial of service. Is this feasible?
I would recommend setting up a RESTful web service first of all. This would allow you to filter requests coming from the Android client by their method, for example only handing POST for certain end points.
If you knew that only an Android client would be accessing your server you could also enforce that a "client" or "auth" token (simply a JSON property) must be sent with every request and you would then only supply this token to the Android client implementation and refuse any attempt to access your server which didn't include the token.
It's also important not to access superglobals such as $_POST in PHP directly, instead use filter_input().
This is just a suggestion and there is much more you can do.
I have an iPhone app that is using my php api on the server but it is currently open if someone knows the url. I want to make sure that no one can use this API until I am ready to make it a public api (if I even do)
I have read this article but I am unsure what they mean when they say:
[CLIENT] Before making the REST API call, combine a bunch of unique data together (this is typically all the parameters and values you intend on sending, it is the “data” argument in the code snippets on AWS’s site)
I don't understand how if I hash the parameters I plan on sending with my api secret how this is more secure than just hashing the api secret if I send the parameters/values unencrypted.
HTTPS the API and use an API key. Then you'll know that only people (you in this case) with the key can have access to the API.
You're correct about it not being more secure. That's why I suggest you SSL the connection. Unless you plan on encrypting everything you transmit back and forth.
The public/private key scenario will also work well. HTTPS requires very minimal effort.
Digital signatures provide a way of validating a message sent over an insecure connection.
Setup: each client will have its own private key and public key (only the private key needs to be stored on the client). The server will store the public keys for each client. The public key can be visible to all and can be used by the server to identify the client. The private key, known only to the client, it is never shown to anyone.
The client signs the request: along with the rest of the request data, the client will hash the combined request data and encrypt the hash with the private key. The server will generate the hash the same way (leaving the signature out of the hash calculation), then decrypt the signature using the public key. If the hashes match, the request is authentic.
Note that HTTPS allows for client certificates, so you can leverage existing tools to accomplish all of the above without writing a single line of server-side code (you just have to configure your web server; the only trick is to make sure the server only accepts certificates it already has). Moreover, the amount of client side code should be minimal: you shouldn't need to do much more than set the connection to use the client certificate. Since you're controlling the clients, you can use self-signed certificates and add the server as a certificate authority. There are a number of questions on SO about using client certificates in iPhone apps; you can start by reading through them.
Note also that any scheme to protect the web API only works so long as copies of the app are in trusted hands. Should anyone untrustworthy get ahold of it, they can use the app or extract any secret data used by the app and access the API as they will.
For development purposes you can just use your web server settings to allow requests from your ip only.