Introduction to Token Based Authentication Using OWIN (Katana) and OAuth

Introduction

Open Web Interface for.NET (OWIN) is an open-source specification that describes an abstraction layer between web servers and application components. It defines a standard interface between .NET web servers and web applications. The primary goal of OWIN is to decouple the server and application, encouraging development of small and focused application components that are part of the processing pipeline through which the server can route incoming HTTP requests. OWIN is a specification, not an implementation.

Katana is open-source components for building and hosting OWIN-based web applications. It provides the implementation of the OWIN specification. This component is maintained by the Microsoft Open Technologies Group.

The OAuth authorization framework enables a third-party application to obtain limited access to an HTTP service. One of the common patterns used for authentication in a web application is the OAuth Resource Owner Flow model.

The following are the principal components of this authentication mode:

• Resource server: It holds the resource and protects the resource from unauthorized access.
  
  
• Resource owner: It requests the resource base on needs.
  
  
• Authorization server: A server that authenticates the resource owner identity and issues the access token to the client.
  
  
• Client: It is an application that requests access on a resource on behalf of the resource owner.

Overview of the Owner Resource Authentication Flow



The resource owner has login credentials and client credentials. The resource owner submits the login credentials and client credentials to the client. The client submits the credentials to the authorization server. The authorization server validates the credentials and generates an encrypted access token. This access token is returned to the client.

In the next request, the client uses this access token to make a request to the resource server. The resource server has been designed to accept the access token and it sends this access token to the authorization server to validate the access token. Based on the response of the authorization server the resource server provides the resource or denies the request.

For a small project we can combine the Authentication Server within the Resource Server.



Mechanics of Token Validation

The authorization server is responsible for validating the input token from the client. It basically does the following three things to validate the token.

• Verify: Token is well-formatted.
• Verify: Token is coming from the intended authority.
• Verify: Token is meant for the current application.

Well-formed

When we say the token is well-formed, the token holds following:

1. The token is correctly formatted depending on its intended format
2. The token contains an expiry time so it has been received within its valid time period
3. The token has not been tampered with

These three tasks establishes whether a token looks good and moves to the next check else OAuth throws an authorization denied exception.

Coming from the Intended Authority

Tokens are designed to advertise their origin as clearly and unambiguously as possible. There are two mechanisms used. Both are used together.

• Signature verification: The key used to sign the issued token is uniquely associated with the issuing authority. Hence the token is signed with a key where the token is originated.
  
• Issuer value: Every authority has unique characteristics. Various token formats will be carried out for information in specific places, like a specific claim type.

A signature verification key and an issuer ID value are available as part of some advertising mechanism supported by the authority, such as metadata, discovery documents.

Intended for the Current Application

A Token contains a claim meant to indicate the target app for the token that is issued. In this process the block system will check the protocol used for determining whether the token is the same as the current app used.



Summary

OAuth enables clients to access protected resources by obtaining an access token. The authorization server is responsible for issuing the token with the approval of the resource owner. A token is defined in the OAuth 2.0 Authorization Framework (RFC6749) as a string. It represents an access authorization issued to the client rather than using the resource owner's credentials directly. The client uses the access token to access the protected resources of the resource server.