Home > Azure > Securing Web API using Azure Part – 2: Designing Interfaces

Securing Web API using Azure Part – 2: Designing Interfaces

This is the part 2 of my 3 part series of Securing Web API using Azure .If you haven’t read the previous post then I highly recommend reading that one as in that post we look into security configuration using the Azure portal as well as developed some understanding of Simple Web Tokens (SWT Tokens).

The link to the first part is at:-


First,I am going to start with a high level overview of the orchestration behind the authentication process and then we will look into our design. This authentication process is bit complex and it involves the three different parties namely.

  1. Client:- Is the consumer of your service.
  2. Azure ACS:- Is the Identity Provider and will provide the SWT Token.
  3. ASP.Net Web Api:- Your hosted ASP.NET Web Api which will validate the SWT Token.

And to represent all the interaction between the above parties at different point of execution I have put together a quick swim lane diagram to show how it all fits together.

SWT Token orchestration

As you can see from the above swim lane diagram I have added some colors and legend to represent what interfaces/classes I am going to define later. Lets examine what are the different steps involved in the SWT Token authentication orchestration process.

      1) Consumer of the web api request a SWT Token from Azure ACS.
      2) Adds the returned SWT Token into the HTTP Request headers with an OAuth specification header.
      3) Consumer makes the call to rest end point i.e. the web api controller action.
      4) ASP.NET pipeline intercept the token request through TokenValidationHandler as it is derived from the Delegation Handler base class defined in the System.Net.Http namespace
      5) TokenValidationHandler delegates the header token to our custom TokenHeaderValidator class.
      6) If the header is in correct format the TokenValdationHandler delegates the token validation to our custom TokenValidator class.
      7) If the token is valid then the control goes back to ASP.NET Web api routing and the requested action is executed.
      8)The results are send back to the client as HTTP response.

Now coming to our design decision the first thing is to have a clear separation of concern and secondly the code is easy to unit test. This is the reason I decided to separate some of the responsibility like token header validation or token validation into its own classes. It is always a good practice to break code into smaller classes so that we follow the Single Responsibility Principle (SRP) and it makes easy to unit test the class.

Lets look into some of these interfaces and classes in their skeleton structure.


public interface IWebTokenProvider
     string GenerateToken();


public interface ITokenHeaderValidator
    bool Validate(
        HttpRequestMessage request,
        CancellationToken cancellationToken,
        out string headerValue,
        out string[] nameValuePair,
        out Task<HttpResponseMessage> taskHttpResponseMessage);


public interface ITokenValidator
    bool Validate(string token);


public class TokenValidationHandler : DelegatingHandler
    protected override Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request, 
        CancellationToken cancellationToken)

One of the code refactoring I like to do right in the beginning of coding is to remove magic string with string literal constants, this way the code is tidy and it is easy to change in just one class rather than searching and replacing in your entire code base. This client/web services interaction involves a lot of magic string and as a result of that I have wrapped all the constants inside a class as shown below.


public static class WebTokenConstant
    public const string Unauthorized = "Unauthorized";

    public const string Authorization = "Authorization";

    public const string AuthorizationHeaderIsEmpty = "Authorization header is empty";

    public const string AuthorizationProtocol = "WRAP ";

    public const string AccessToken = "access_token";

    public const string InvalidToken = "Invalid token";

    public const string AuthorizationHeaderWasNotSent = "The authorization header was not sent";

    public const string InvalidFormEncoding =
        "Invalid form encoded string - contains a name/value pair missing an = character";

    public const string DuplicateNameValuePair = "Repeated name/value pair in form";

    public const string UrlFormat = "https://{0}.{1}/";

    public const string WrapName = "wrap_name";

    public const string WrapPassword = "wrap_password";

    public const string WrapScope = "wrap_scope";

    public const string WrapAccessToken = "wrap_access_token=";

    public const string WrapVersion09 = "WRAPv0.9/";

    public const string Post = "POST";

    public const string AccessTokenHeader = "WRAP access_token=\"{0}\"";

    public const string ClientAuthorizationHeader = "Authorization";

    public const string IssuerLabel = "Issuer";

    public const string ExpiresLabel = "ExpiresOn";

    public const string AudienceLabel = "Audience";

    public const string HmacSha256Label = "HMACSHA256";

That’s it for now and in my next post I’ll cover all the implementation of generating and validating SWT Token.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: