views:

33

answers:

2

We have a Windows app hosting a WebBrowser control that hits our REST APIs. We like to restrict access to the APIs to be only coming from withing the Windows app itself (for example, the APIs cannot be accessed in a browser, etc).

How can we accomplish that? what is the most secure way without having to expose any kind of credential (for example, if we use HTTP Basic auth, the username and password can be seen by reverse engineering the app itself)?

Thanks a bunch!

EDIT: We plan to distribute the application freely so we have no control over where the connection will be made from.

A: 

Restrict the REST interface to only accept connections from 127.0.0.1 (home) and then connect from your rest-consuming application only with http://localhost or http://127.0.0.1 in the URLs (if you use the external IP or DNS name of your machine it'll be treated as a remote connection and denied access).

You can do this with web server settings, or within the code of your REST APIs

Rudu
We plan to distribute the application so we have no control over where the connection will be made from.
TopQ
127.0.0.1 is the universal IP for the internal network inferface of the machine - any computer (Linux, Unix, Windows, Mac) understands both localhost and 127.0.0.1. If you're distributing then you'll want to be coding that restriction into your REST APIs so you don't rely on end-user web server configs.
Rudu
Can you elaborate more on that? I don't quite understand how does "listening" on localhost can help? I am the service provider and am also distributing the application to access the services without any sort of user signup process.
TopQ
In your REST code - whatever language it's in, you need to check the IP address of the connecting client. By denying all but the IP 127.0.0.1, only connections from within the same machine as the REST API can connect. That traffic therefore never goes over the network.
Rudu
The app will be distributed over the internet as a free app that everyone can download and use.
TopQ
A: 

I had a similar situation during a project where we distributed an iPhone app that also connected to a REST api that my team developed.

For security we used somewhat of a three-legged scenario. The app was required to authenticate using the user's credentials against a standalone service responsible only for authenticating and generating access tokens. Once the app received a valid access token, subsequent requests to the api required sending this token in the Authorization header.

You could do something similar. If you come up with a credential scheme to authenticate your app as valid API consumers you could use basic auth over HTTPS to obtain tokens, and then only by using those tokens could a consumer gain access to the rest of the API.

Andrew Church
Does the token change over time or stays the same to the same user? If it stays the same, wouldn't the user of the iphone be able to use it in any other way outside of your app?
TopQ
The tokens are unique to each user, and each one has a lifetime, and validating that the token is within the allowed lifetime is part of the validation process, as well as a couple of other fields specified when it's generated. Tokens are also encrypted on the server before being returned.
Andrew Church
The difference with what we're doing is ours is based on user credentials, not specifically limited to our iphone app. You'd need to come up with a similar way but validating your app vs. validating a user.One way you could do that is by issuing a certificate with the app and use that for client validation.
Andrew Church