im not sure of which way to take with a REST API im currently developing using CakePHP, i haven't implemented authentication and until now that im almost done with it i'm reading about it,
but i'm not sure of what should i do, this API would be exposed so that a webpage and a mobile app can consume it, but i dont think Basic auth or Digest auth (which come as default options in CakePHP) are the option,
i only know that i need it to check username and password from the database, and grant permission according to an ACL that is already set up, i was reading something about HMAC but dont understand it completely, should i make an authentication method on my own that does something like check a token? is this article correct? : http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
and if so, how do i implement those principles to the CakePHP auth method? is there a plugin for this auth method using HMAC?
should i use OAuth 2.0? does it make sense to use OAuth 2.0 for a username & password login? am i too lost? if im not so lost, could you please describe how to implement OAuth with username and password in cakephp?
someone, please, anyone surfing this interweb forum, HELP ME. if you could provide examples or workflows, anything, everything will be greatly appreciated.
How much security do you need? As an API is usually accessed from a client app which has the keys, it's usually OK to send the credentials along with every (https) request (as POST parameters, so they'll be encrypted). At least, this is by far the easiest solution: You just check the credentials with every request, without any sessions, tokens and the like. If the credentials are valid, you check whether that now authenticated 'user' is authorized to access the requested resource(s).
Remember that more advanced authentication/authorization methods quickly become complex in development and management. If you don't have any experience in implementing such systems, it's rather likely you're obsoleting the possible security gain with implementation bugs/issues.
Related
After building a fairly simple API, I started looking into authentication where the basic HTTP authentication over SSL with just a username/password combination may appear weak for someone using it, although various discussions on here suggest it should be fine.
As this is the case, I looked into the API's from similar solutions which provide their users with a user ID and an API Key instead. The problem is I don't see how this is any stronger at all. I assume the Key is still saved just the same as a password, where from my perspective it just looks like they are calling a password a key.
Example:
https://github.com/Arie/serveme/blob/master/spec/fixtures/vcr/HiperzServer/_restart/visits_the_Hiperz_restart_URL.yml
How does the &api_key=hiperz_api_key&gs_id=3873 args offer any further security than just a username password? I would definitely like to implement something stronger than just user/pass over basic HTTP authentication and provide the end user with some type of token/key to use for access, but I am failing to see the additional strength from such approaches.
Well, there is always 2 step authentication which can be done(either by sending a message to their phone .. or maybe giving each user a randomly generated code to fill). Also, you can create your own encryption mechanism and add it to the functionality of your webpages. For example, you can encrypt the data using your own made up encryption key and then when it reaches where you want it you only know the key so you can de-crypt it.
Basic authentication is not recommended to protect APIs as I tried to explain in my answer here.
You are correct that using a client id and client secret is very similar to username and password authentication. The difference is that in the latter case you authenticate the user (a person), where in the former you authenticate the client (an application).
Whether you want to secure your API with a client id and secret depends on whether you can trust the client to keep them secret.
Either way, whether you have a trusted client, like a web application (living on a secured server) or an untrusted client like a JavaScript application or mobile application (living in the user's realm), token based authentication schemes (like OAuth2) provide a more secure way to protect your API than basic authentication. See my answer here for more information on the different ways to get tokens using OAuth 2.0
I am learning API's at the moment as well. My understanding is that by using an API key you can have more control over what permissions the user has. Also the API key can be reinvoked at any time as well. Also it will save the customer time from inputing log in details on each use of the API. I am not sure if that answered your question or not.
I'm developing one android application and I'm creating a php based webservice to retrieve the information from the database.
The thing is that I really don't know how to secure this service.
For example, if my android application needs to retrieve some information from the server it will call http://mywebservice.com/service.php, and it will send several POST parameters as the user and password to login, or something like, for example, one user id to retrieve his data.
Of course, anybody with the knowledge enough will be able to retrieve that data too. And this is what I don't want to happen.
Anybody who know the parameters to send to my server will be able to retrieve information from it.
How can I secure this?
I've been reading about OAuth, OAuth2, two legged and three legged implementations of it, https..
But at the moment, I really don't know how to secure this.
I want that the webservice only answer to my application and not to anybody else.
PS: Even there is something like http://myservice.com/get_information.php that you send an id and you can retrieve a lot of information. Of course, I control that in my application, only logged and authorized people can do that calling, but it's a problem anyway. What's the best way to do this kind of things?
Some concepts to secure a webservice(might be forgetting some notions):
Protocols: HTTPS in the current case so data are not transfered in a clear format.
The Sessions: A session has a lifetime, a unique identifier(session token/id/whatever) and contains an error code. When a user will call your webservice, a session will be created and its token answered back. At every call of the webservice you'll test if the session is still alive. You can add complexity to the expected inputs, outputs and exchanges. The error_code will be used for logging(errors can come from an attack or a bug of your webservice).
Data Encryption: Use asymetric functions like password_hash() or crypt() for authentication issues. Use symetric algorithms like AES 128(10 rounds) or 256 (14 rounds) for sensitive data you'll need to retrieve.
Testing inputs: If you find yourself inserting given arguments in a query, try to prevent SQL injection. Some bad-minded people can also try to send arguments which would make your webservice fail.
Go for standards: As Çagatay said, try to implement for example oAuth2 because standard is most of the time much better than what we'll build :S
Hope it helps.
edit: The REST security sheet is good also.
Always use SSL to prevent some man-in-the-middle attack. Otherwise someone that sniffs the connection (in case of connecting via public wi-fi or company networks it's a huge risk) can see the username and password.
Do not send username and password on each request, instead implement oAuth2, your client in this case will have to send the username and password only once and then for the other requests you'll have to send only the auth key. Good documentation for implementing a oauth server: http://www.sitepoint.com/creating-a-php-oauth-server/
Look at this document: https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
I ended using OAuth. More especifically this library https://bshaffer.github.io/oauth2-server-php-docs/
If you follow the instructions it's really easy to use and it works very well. I think it's a really good way to start working with OAuth.
I'm programming an online database based app, but at least the authentification is missing!
A friend of mine says I should use oauth, but I don't understand, why this is secure!
If there is a hacker, he would see this key at all and could get in with his own request, wouldn't he?
Does anybody has an example, why this isn't the case?
And maybe some code tutorial how to implement this with php and objective-c?
Thank you! :)
The insecurity is that you are trusting the site you are authentication against to have good security policies. I don't trust that for my usage, it may be fine for you. You need to define what you are securing and the value to both you and your users.
So, use oath if it meets you security needs. It it doesn't then hire a security domain expert to create your custom authentication.
I'm currently developing a RESTful API in PHP an I'd like to implement some user authentication to it. I have read through some literatures and the most efficient/secure way to allow authentication through rest api seems to be the use of the access tokens via the oauth protocol.
I have understood the way the protocol works but I don’t understand how to implement it to our api & database when the user has got his access token. The documentation about it is very unclear/nearly non-existent...
My idea was basically to save this access_token in my "users" MySQL table. That way we could verify if the user exists and has the appropriate permissions during each requests on the API.
However I’m not sure it is the most proper way to do that. Is it safe enough? How would you personally proceed to deal with that?
As this access token is like a temporary password, you can indeed store it in your table.
But as with storing passwords, you might want to hash and salt the token (depending on how relatively easy your tokens can be guessed). See the why's and how's here:
Secure hash and salt for PHP passwords
Back from the Symfony Live 2012 in Paris, where I luckily participate to "Designing HTTP Interfaces and RESTful Web Services" conference, I'v much questions on how to build a RESTful API while keeping it private and member only.
Currently I used to generate an API key to make my API private (I mean available to third-party application on my own but end-users).
To make sure signed up users can use the API (through mobile app) I use Cookie, well, I used SESSION.
But afaik, it is not the correct way to do, according to the talk (and other resources I read over the web).
My needs are the following:
Provides a private API which only my mobile app can use
Allows member (of different roles) to do different actions (ie: a Member can post a comment, while an Administrator can edit them all)
As REST constraints are Stateless (amongst others) I can't use Cookie/Session as they need to be initiated by the client and will result in some non-idempotent result.
I read here and there that a way to keep my API RESTful is to provide on each request the credential.
Currently, to authenticate my API key (to keep it private) I use a custom HTTP Authorization scheme, something like Authorization: MyApp SoMeToKeNV3RYPR!V4T3 and then authenticate my member (login) with a POST method (as I would do in any browser web application).
How would you implement such cases? Is it acceptable to use such private scheme and keep using sessions?
After some reading I may think that working with some Signature over each requests can help to solve such problems.
The signature may be generated using the user credential provided in the third-party client while encrypting it with a public/private key (to keep the API private).
On each request, the signature will be checked against a CRC (or something like that) while the credential will be against a database (it doesn't seem worth than checking for a session, does it?)
Any help/advices would be appreciated.
PS: What about OAuth? I don't know much about it, but may it be a solution to such problem?
You're definitely going to want to use OAuth. This will allow you to securely authenticate that your users are who they say they are. No messing with CRCs or anything is needed on your end, once a user is authenticated they have an access token they can use to sign future requests.
You would just need to handle the authentication scheme and handshake and then securely store the access tokens once they have been given out. However, if it were me I would not trust myself to handle all of the secure cases when designing such a system. There are a couple of third party PaaS companies that will do this type of thing for you. I know of the following companies which have some API management tools that will probably help you, and afaik they handle OAuth implementations as well:
Apigee
Layer 7
Ping Identity
If you are so concerned about security though that you don't trust a third party to handle it for you you are going to want to follow the OAuth protocol.