Securing your web service by using a token

There are a few common approaches to securing your web service, or specific methods in your web service. In this post, you will learn an approach that uses a security token.

The information in this post is valid only for the Fall 2010 version of WSA500 and DPS907.

.

How does this solution work?

The programmer decides that some of the web service methods (i.e. URI templates) require authentication. Maybe the methods will expose private information, or perhaps the methods modify the data (with PUT, POST, and DELETE operations).

In each method, the code checks whether a security token – which is an encoded and/or encrypted string – has been included with the request. If not, the HTTP 403 status code is returned to the requestor.

If the security token was included, the code checks whether it is valid, by performing a lookup in a token store. If the security token is not found, HTTP 403 is returned.

However, if the security token is found, the rest of the method’s code can be executed.

.

Components needed for this solution

A small number of components are needed for this solution to work:

A store for the security tokens and/or credentials: The store could be local to the web service, or remote via a web service call. The important idea is that we need a store.

An app that enables account sign-up and management: A web app, maintained separately from the web service, would have the necessary user interface and infrastructure to enable a user to request a security token, and generally manage their account. The creation and maintenance of this app will NOT be covered in this blog post.

A properly-configured request: The requestor must include the security token with each request to a protected method. The security token will be presented in a request header.

Web service method code: In each protected method, the program code will check the security token. If valid, the request will complete successfully.

Let’s look at the components in more detail.

.

A store for the security tokens

In the professor’s solution, a new database table was created, and then surfaced in the Entity Framework (EF) data model, as the “APIKey” entity.

It is a simple entity, and captures only some of the ideas needed for a complete solution.

The “APIKey1” property was designed as a string property, which can hold an arbitrary string. The format and content of the string is beyond the scope of this post. For this example, your professor simply created (somewhat randomly) alphanumeric strings, 10 characters in length.

.

A properly-configured request

For this solution, your professor decided that the security token will be included in an HTTP request header. A custom-named header was specified, called “X-SCSToken”.

Therefore, whatever your (client-side) requestor platform is, just make sure that you create the custom-named header, and set its value to your security token.

Using the WSA500/DPS907 Lab 2 web form, if you add another text box for the security token, you can include it with the request, using the following code:

Incidentally, some public web service APIs require the security token be included in the URI query string. We are not making any “best practice” judgements here; we simply wanted to use an HTTP request header to carry the security token.

.

Web service method code

For each method that we want to protect, we want to check whether a security token has been included with the request.

A code example is included below. You may want to adapt and refactor it to improve its quality.