I am developing an apple app which talks to a restful PHP web service.
Ideally i want this web service password protected.
What is the best way of achieving this,
Is it better to use a technique similar to OAUTH or is it over kill?
Or is it better to send user password and username in server each command and check its legit before caring out each individual command.
Thanks
It depends on the client. If the client is 3rd party, then it needs an OAuth like solution with access tokens. If the developer of the service and the client is the same, then the basic auth approach is enough. Ofc. you have to use encrypted connection.
Related
I have a web-service which is used to create entries in the Database hosted by GoDaddy and the web-service are written in .net and this web-service or url will be only used in the Mobile Platforms like IOS and Android.
Now I have few questions?
1>How can I secure my URL(web-service) and its content from getting exposed?
Currently I have used post method so that I can hide the parameters but still I fear the URL might be hacked so please suggest a way to secure.
2>Regarding the contents I want to encrypt the data and send to server and in server side it will be decrypted .
Now please suggest me an algorithm or code which can be used across platform like IOS,Android , .Net
Thanks and Regards,
Anil
Use HTTPS
Use login/password auth (no access at all without login and
password)
This is a similar situation to the one raised in this question:
Javascript Calling a Rest API with App Name and App Password - How Can i Secure it
Here is the architecture overview:
The site is Html5/jquerymobile
It contacts what I call a "Wrapper" service.... This is a REST API I wrote in C#, to contact another 3rd party REST API. I do this because there are credentials in the Header and the API uses Basic Authentication. Credentials are therefore not publicized as they are only known server-side.
My "Wrapper" service does not currently implement any additional security. It is currently accessible from anywhere. The easiest and quickest way to lock it down is to restrict by IP, so no other IP anywhere except the server can actually contact my wrapper service.
The questions:
Is the locking by IP the only way to ensure that the API won't get hammered if it was otherwise accessible from anywhere?
If I convert this using Phonegap (which I have... and deployed successfully on Android), obviously the native app won't work if the web service is restricted.
Is there a way around this so I can allow traffic only from the mobile app, and not from any other source? I'm thinking along the lines of MD5 hash or something that could be sent to the wrapper API.. but unfortunately I'm thinking that info can easily be "sniffed".
Is my only viable option here to release the app as a web app, forcing browser use, thereby removing any concerns about allowing my web service to be hammered??
I believe the answer to this is a combination of a user token and encrypting the message through SSL.
The server can issue a valid user a token so we can identify him in future requests.
Encrypting it via SSL will ensure that this token cannot be sniffed.
https://security.stackexchange.com/questions/12531/ssl-with-get-and-post
I'm building a restful web-service based on Spring. I'm using Spring Security. It will be accessed only by desktop applications. Basically a machine-to-machine web-service.
I want a custom service that does the authentication. Then perform other, more sensitive operations based on the result of the authentication.
Another option is to send the credentials in the body of each request and basically do the authentication each time.
Logic says that the first approach would be the most efficient because there is quite some overhead in authenticating each and every time.
What do you suggest related to this? To go stateless or stateful? Are there major disadvantages to the stateful approach?
Up to this point I read some chapters from Java Web Services Up and Running
and also several questions from SO such as this.
The REST way to do this is, as stated in the links you provide, to authenticate on each request, and NOT to keep sessions.
As for authenticating with username/password on each request, it is secure if you can use ... a secure layer (https); else, the pair is sent in clear text and discoverable.
Another option is to use something like the AWS way to do it (Links to Amazon here and here, for example). Here for other explainations : buzzmedia and samritchie
Maybe OAuth is an option, but I don't have experience with it.
To start with REST Service (Client - Server) I will strongly recomend you to use Restlet
Authentication to this REST Service can be defined using ClientResource. Example :
private static ClientResource getClientResource(String uri) {
ClientResource clientResource = new ClientResource(uri);
clientResource.setChallengeResponse(ChallengeScheme.HTTP_BASIC,
"username", "password"
);
return clientResource;
}
frontend dev here with no experience with SSO so bear with me. Keen for a high-level recommendation on the following as I can appreciate it may vary.
We've got a client setting up SSO to login to our site, and Im trying to understanding how I can safely call their webservices for user info from our domain via AJAX. Looking at their services they're asking for a User ID and Password which I dont think is usable/feasible as I assume our system would need to expose the password to the frontend which doesnt seem secure... They mentioned they could pass these via http but that doesnt seem secure either!
Is there some sort of way we can validate the webservice all via SSO or is there some other way?
Thanks
Further my comment, we're pushing ahead with using the shared encryption method used for our SSO (TripleDES in ECB mode) to encrypt the token in the webservice request
I am making heavy use of async requests by Javascript to the webserver. Since I am building a multitenant application, I want to restrict access to the json services on the user level.
I read a lot about OAuth being recommended for consumer authentification. In my scenario, would the Javascript (client) side be regarded as the consumer and, hence, would you recommend using OAuth for that purpose? If not, what alternatives would you recommend?
OAuth is best at providing a method other than direct sharing of username and password with third party applications or web sites. I would use OAuth or something like it only in the case that you need to provide this type of third-party access to your web application.
If the JS client will be running in a web browser that the user has already logged in to your service, you might just as well use the session cookie that you have already established to authenticate each request.
In fact, such a session cookie will automatically be shared as part of any XHR to your web service.