How to implement Authentication and Authorization for my Web API web service?

Question

I have a Web API Web service which is used by a number of client applications with different technologies like Java, .NET, etc. Therefore, my user credentials are stored in a separate database.

My Web Service is hosted within IIS and I have configured and enabled SSL on the server side which makes sure that the Request/Response Messages are encrypted and signed.

I've also configured IP Address Restriction feature of IIS to allow the requests from a handful of known IP Addresses.

I don't like to use Basic Authentication since it sends the credentials in plain text with every single message although the message is encrypted using SSL.

I can't use Integrated Windows Authentication obviously because my users are not on the same domain as my server.

I can't use Forms authentication since my clients are not browser-based.

So what's the best way to implement Authentication and Authorization for my web service?

I was thinking one approach would be to provide an Authenticate(username, password) web method which behaves like an Identity Provider/Security-token-service and generates a token specific to that user which expire after certain time. Then the client must be sending the authentication token with each web method request and I make sure of it by creating a Custom Authorization Filter for my controller.

The advantage of this approach is that the user doesn't have to send username/password with each request but just a temporary token. The disadvantage is obviously managing the token life; when should it expire? e.g. if no request was made within an hour.

What's the best way to implement Authentication and Authorization for my web service?

Answer 1

I will address options for authentication in my comments in respect to SOAP services. Authorization is implemented within the server application and mostly irrelevant to the authentication type selected. There are three (3) classifications of web services: -Private -Community -Public

It sounds like the web service you are providing is a community service because it is only available to trusted partners. I know this because you explained that an IP Address restriction was configured in IIS. Including an IP Address restriction is one of many good measures for implementing secure web services. Security is not a single thing. It is an accumulation of many defenses. IP Address restriction is a good start.

Web Services are stateless by nature. Therefore, it is typical that the credentials (username and password) must be included with every request when calling a web service. So, it is not a problem or concern.

HTTP Basic Authentication is not a bad choice. It is supported by all client and server applications and easy to implement. I like to think of HTTP Basic Authentication as the lowest common denominator. I would not rule it out. HTTP Basic Authentication includes the credentials in the http header in plain text so it’s always recommended to include SSL (HTTPS) to encrypt the transport channel.

WS-Security is a very common authorization standard for Web Services. It is an industry standard for Web Services and the specification is published by the Organization for the Advancement of Structured Information Standards (OASIS) organization. WS-Security includes a UsernameToken profile for including username/password. The WS-Security block is added to the header of the SOAP message. In comparison, HTTP Basic Authentication is added to the HTTP header. HTTP Basic Authentication is attached to the transport protocol. In comparison, WS-Security is attached to the SOAP message. WS-Security UsernameToken is in plain text so it’s always recommended to include SSL (HTTPS).

Another option is client certificate authentication. This option uses a digital certificate as the authentication token in lieu of a username/password. This method works well but requires that the web services team members and client application team members both be familiar with SSL digital certificates as a prerequisite. The learning curve for this method is higher than the others.

The custom solution you described is not necessary, because so many industry standards exist to implement and solve the solution you seek. For example, if you implement WS-Security in your web service, you do not have to provide the client app team with documentation and explain how to implement it in their client application. WS-Security is an industry standard that is well documented and supported by most modern SOAP servers and SOAP clients today. The same applies to HTTP Basic Authentication.

I hope this helps. Cheers, DCova

Answer 2

IP addresses can be spoofed very easily, so don't rely upon them to secure your service.

I would suggest that you allow access over HTTPS only, and to secure it further, verify the certificate with which the request was signed. Even better, have your own certificate server and issue your own certificates for this purpose.

Answer 3

In facebook, they provide an access token to the application that changes only when the password is changed or the user specifically de-authorizes the application. you many consider this approach. This is done similarly in Google's Map API's. The only safe way I can think is to check from where request is coming (IPaddress of the request) and then check for apikey and then respond.

Answer 4

My Web Service is hosted within IIS and I have configured and enabled SSL on the server side which makes sure that the Request/Response Messages are encrypted and signed.

SSL is transport security and not message security. It does not sign the message for you. It encrypts the channel.

I feel the approach of pre-shared keys or API key will work the best for your case. Since the users have a user id and password, I assume they register somewhere. As part of the process, generate a key, which can be a shared symmetric key, that is, both parties (client and server) have the same key. Client sends the user id in the Authentication header in some custom scheme and the SHA256 hash of specific part(s) of the request message. Server gets the user id, retrieves the key, computes the hash for the same part of the message and if hash matches, the client is in.

Check out my book Pro ASP.NET Web API Security.