What is the best authentication method for web service

Question

We have a .NET web services API. People currently use the SOAP definition to use the API because we require authentication through a custom authentication element in the SOAP header. Works great. OK.

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

So, what is the best way to offer a simple GET API (it’s not necessary to be a web service!) 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 do not want to implement SSL and do not install additional software or plugins in IIS, etc. etc.

Answer 1

If the web service is to be protected, and I assume that it exists, since you currently have an authentication header, then you should reconsider using GET and not use SSL, at least for the authentication part. At a minimum, I would put an authorization request via SSL in a web service / application. If you do not want to provide authentication for each request, you will need to accept back (and generate in the service) an authorization cookie, which the consumer can use for subsequent requests.

I would not use authentication in the URL for the very reason that you want to support GET - if the URL can be cached, then the credentials will also be cached. This violates the security of the web service because anyone can reuse cached credentials.

Answer 2

If your clients are in the same domain, you can enable integrated Windows authentication in your IIS application. Now your application will only accept authenticated Windows users. Add your own RoleProvider for finer, role-based detail.

Answer 3

Using only the GET API, I will have the first method that retrieves the unique session identifier.

For example: GET / api? action = auth & username = user & password = hashedpassword Would return a 16 character token that you store on your side, and you need this unique token for each subsequent call.

If the API was executed in PHP, you can use its PHP session processing functions to achieve this goal (it has a timeout / garbage collection). Similar features exist in ASP.NET.

It is vulnerable to re-attack (someone captures or guesses the session identifier), but if you need something simple, this is the way to go. Any non-HTTPS website will be vulnerable in the same way. You can associate a session ID with a user's IP address for added security.

Answer 4

If you use WCF, you can use the built-in security mechanisms. If you do not want to use a standard framework for security, you are most likely to do security through obscurity.

Answer 5

Like Thomas Aid, answer: you can use a single login system, such as siteminder, to protect the URL. The caller requests the need to include a token, which is usually 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 it does not use SSL.