I'm about to replace my oldfashioned sessionbased server solutions with RESTful ones.
Where can I find information about design principles concerning security, authentication etc. when moving into this stateless domain?
I need to find solutions that work with different client platforms (Flex/Air, Browser, desktop and mobile apps etc.). Right now I work with php in the server end.
OAuth 2.0?
The easiest is basic http authentication; http://en.wikipedia.org/wiki/Basic_access_authentication
Learn from examples like Google accounts authorization, Yahoo REST APIs etc.
Some points to notice:
Cookies are usually used as
out-of-band authentication tokens.
Beware of AJAX calls failing
authentication - if they get a 302 redirect to a form, it will be followed automatically and you'll get a 200 response with the form body as a response
Related
I'm in the process of developing a system which is heavily dependent on a web service which is designed according to REST principles. The connection is over HTTPS, and my issue is finding a good way to identify clients. There are several users from several different companies with several different access levels.
The backend/middleware is written in PHP, and up until now, I have used the $_SESSION to identify users.
After reading more about REST services, I learned that REST services should be stateless and every call should provide all information necessary to handle that call. I interpreted this in the direction that the server should not maintain any states related to specific clients.
Questions:
Does this mean that using $_SESSION[some_identifier] to preserve state between calls is not aligning with the REST style?
I'm now considering using a "short-lived token" logic instead. This token is exchanged with the server on each request, and the server provides a new token in the reply of each request. Is this approach more RESTful?
You should be using the Authorization HTTP header, used by various HTTP authentication systems such as Basic, OAuth2, or your own proprietary extensions.
I have a main website (which contain all data) and multiple client websites which fetch data from the main website. Each client website has access to different set of data on main website. I want to create a PHP based web API for this. This is my first API so I am not sure what is the best and most secure way to do this.
After some googling I found OAuth to be the most common authentication method for APIs. however in my case I want the client website to be configured once and then the communication should be automatic, i.e. communication should take place in background without any user interference. Is OAuth required for this scenario?
Or is there any other method I can implement here?
oauth is way to complicated to implement for your needs.
If you are using rest, i suggest using a basic-auth in the header and using SSL so that your communication is encrypted.
You could make a small SecurityFilter that checks if for any request with a url pattern /api/ that the basic-auth is correct and that it use SSL...
It really depends on how you are exposing your API.
If you are using REST, HTTP Basic Auth over HTTPS is sufficient. I see a lot of people try to implement their own solutions when the provided approach is quite sufficient.
If you are using SOAP, there is a SOAP-based approach you could use: WS-Security (which is just a standard using anything from SAML assertions to OAuth tokens).
If passing Basic Auth credentials over HTTPS is too "open" for you, in that the credentials are saved in config on the client server somewhere, OAuth2 is probably the best solution. Doing OAuth on the server side wouldn't require any user interaction. You just store your tokens in a server config and let the OAuth library take care of the rest. PHP has a library for this PHP OAuth Library. There are plenty of OAuth2 libraries for PHP. Just Google it.
After some more googling and research I found answer to my question:
The scenario I explained is an example of 2-legged oauth (one can find many articles about 2-legged and 3-legged oauth)
Also, OAuth is not difficult to implement, infact for a developer with good knowledge of API and Auth system its very easy.
Here's a link of very good php OAuth library with example code http://code.google.com/p/oauth-php/
I have an API written in PHP that works by receiving HTTP POST requests, the API will then process the request and output some XML.
I have an Android application that is communicating with this API successfully.
My question is how do I make this secure?
I was looking into using OAuth, but for PHP it uses a library that is not available to me.
Plus as the API is not public and only to be used by external applications created by myself, this seems a bit overkill.
What other suggestions would you recommend? I was looking at sending an API key/signature along with the POST request.
It should be done the same way you make javascript calls secure. You use sessions. You should be able to send and receive headers, why not accept cookie-like data? At least session_id. Securing with SSL for open wifi hotspots would also be very beneficial if you use symmetric authentication.
OAuth has a different purpose - its when your website starts to host third party applications that users want to use without giving this app own password.
I'm developing a social networking website. This service will be available across various mediums, for example: the web, iPhone, Facebook application etc.
My idea for this application was to have all of these properties interact with one central point for fetching and saving data: an API. My various applications would then interact with this API, sending a GET request to fetch some data; a POST request to submit some data; DELETE requests and so on.
This API will be web-accessible, so I need a way to authenticate only white-listed applications. This API will never be available for third parties to interact with or build third-party applications with; it's to facilitate my applications only so I can cut out re-coding solutions across various platforms and focus only on the logic (controllers, essentially).
Therefore, would OAuth be suitable to be used as the authentication method for the above scenario?
My knowledge of OAuth isn't great, but if it is deemed a viable solution then I'll obviously read up on it before implementing. But as far as I know it works on tokens. A consumer (for example, my website) would request a token from the application (the API in this instance) and then the application would return a token to use in subsequent requests. Or something.
When a request comes in to my application, am I then able to accept/deny requests based on the requesting application? I.e. can I deny access to applications that aren't my own? How do I differentiate between applications? Do I retain a whitelist of IP address or URLs, and compare upon incoming requests?
Any help on the above would be most appreciated.
OAuth is not designed to authenticate some applications the way you want to.
Juste create your own private way to authenticate, because you're the only one to know about your API. Dont forget to pipe the authentication in SSL and everything will be ok !
I don't think OAuth is the best solution for your problem. OAuth is great when you plan to give your API to the 3rd parties as it allows to authenticate user without giving users's credentials to the 3rd party. If you have all control over the API there is no need for this.
It's still a good idea to read about it thou. :)
I'm working on developing a native android application to retrieve data for a user from my company's website.
Because the data is specific to the user, I need to authenticate with our web server, but I'm unsure of the best way to go about this. I've been reading about REST/SOAP/HTML form auth, but I can't really find any definite 'this is how its done' anywhere. I know mobile apps do this kind of thing all the time - just look at facebook/skype/any email app - you have to login before you can do anything.
My question is - how should I architect the server side code (php) to easily allow me to authenticate a user from my android device?
I'm fairly new to the 'web service' arena - does this fall into that category? Are there any tutorials you guys would recommend looking at?
Thanks!
While I haven't developed for Android, I can suggest that you simply rely on some stateless authentication scheme, such as HTTP Basic or Digest. This means that the credentials will be passed with each and every request, and you avoid having to keep track of state, which means you can keep your API nice and RESTful.
I suspect if I were writing an android app, in most cases, I'd probably first try to get communication working with something at-least-vaguely RESTful, using HTTP Basic auth, and JSON encoding (just because PHP makes (de)serializing JSON so easy).
Of course, depending on your problem domain, that might not be ideal, but it's a good architecture to try first, because it's pretty easy all-around. If it fails you, you can go back and start swapping parts out, until you find the right architecture.
Some mobile apps use OAuth to authenticate with a web server, such as twitter has. This may not be exactly what you're looking for, but none-the-less here's an example: You would log in to web service and authenticate the mobile app (which would have requested access) to be able to utilize your data on web service, like an access key (actually called a token) with which the mobile app then utilizes to communicate with the web service on your behalf; the token could be then passed as part of the url. You'll still likely want to consider SSL or some level of encryption.
This post may also be of help for you