What is the best way to have Authenticate for a Web Service

Question

Hi folks,

We have a .NET web service API. Currently, people use the SOAP definition to consume the API, because we require authentication through a custom Authentication element in the SOAP header. Works perfectly. fine.

SOAP requires the request to be a POST. We want to allow the users to use a the GET verb (so it can be cacheable).

So, what's the best way to offer a simple GET API (doesn't have to be a webservice!) that also offers authentication?

example API route:

http://www.blah.com/api/Search?query=Foo

Is this an acceptable and common practice?

http://www.blah.com/api/Search?query=Foo&Key=<some guid>

NOTE: I also don't want to implement SSL nor install extra software or plugins in IIS, etc. etc.

Answer 1

If the web service needs to be secured, and I'm assuming that it does since you currently have an Authentication header, then you should reconsider using GET and not using SSL, at least for the authentication piece. At a minimum I would POST the authorization request via SSL to the web service/application. If you don't want to provide authentication on every request, then you will need to accept back (and generate in the service) an authorization cookie that the consumer can use for subsequent requests.

I would avoid using authentication in the URL for exactly the reason that you want to support GET -- if the URL can be cached, then the credentials will be cached as well. This breaks the security of the web service since anyone can reuse the cached credentials.

Answer 2

Anyone have any experience with proving the key/guid/authorisation key as part of the querystring?

Answer 3

Using a GET only API, I would have a first method which fetches a unique session ID.

Eg: GET /api?action=auth&username=user&password=hashedpassword Would return a 16 chars token, which you store on your side and you require this unique token for every subsequent call.

If the API was done in PHP, you could use its session handling functionality of PHP to achieve this (it has timeout/garbage collection). There are similar functions in ASP.NET.

It is vulnerable to replay attack (someone grabbing or guessing the session ID), but if you want something simple, that's the way to go. Any non-HTTPS website would be vulnerable in the same manner. You can tie the session ID with the user's IP adress for additional security.

Answer 4

If you are using WCF you can built on the built in security mechanisms. If you don't want to use standard frameworks for security, you are most likely going to do security by obscurity.

Answer 5

If your clients are on the same domain, you can turn on Integrated Windows authentication in your IIS application. Your application will now accept Windows authenticated users, only. Add your own RoleProvider for finer, role based granularity.

Answer 6

Similar to Thomas Eyde's answer: you can use a single sign-on system like siteminder to secure the URL. The caller request the needs to include a token, which usually is stored in a cookie, but can be added to the query string.

Any SSO or web service management platform will intentionally make authentication difficult if not using SSL.