Token Based Authentication using ASP.NET Web API 2, Owin, and Identity

Last week I was looking at the top viewed posts on my blog and I noticed that visitors are interested in the authentication part of ASP.NET Web API, CORS Support, and how to authenticate users in single page applications built with AngularJS using token based approach.

So I decided to compile mini tutorial of three five posts which covers and connects those topics. In this tutorial we’ll build SPA using AngularJS for the front-end, and ASP.NET Web API 2, Owin middleware, and ASP.NET Identity for the back-end.

The demo application can be accessed on ( The back-end API can be accessed on ( and both are hosted on Microsoft Azure, for learning purposes feel free to integrate and play with the back-end API with your front-end application. The API supports CORS and accepts HTTP calls from any origin. You can check the source code for this tutorial on Github.

AngularJS Authentication


Token Based Authentication

As I stated before we’ll use token based approach to implement authentication between the front-end application and the back-end API, as we all know the common and old way to implement authentication is the cookie-based approach were the cookie is sent with each request from the client to the server, and on the server it is used to identify the authenticated user.

With the evolution of front-end frameworks and the huge change on how we build web applications nowadays the preferred approach to authenticate users is to use signed token as this token sent to the server with each request, some of the benefits for using this approach are:

  • Scalability of Servers: The token sent to the server is self contained which holds all the user information needed for authentication, so adding more servers to your web farm is an easy task, there is no dependent on shared session stores.
  • Loosely Coupling: Your front-end application is not coupled with specific authentication mechanism, the token is generated from the server and your API is built in a way to understand this token and do the authentication.
  • Mobile Friendly: Cookies and browsers like each other, but storing cookies on native platforms (Android, iOS, Windows Phone) is not a trivial task, having standard way to authenticate users will simplify our life if we decided to consume the back-end API from native applications.

What we’ll build in this tutorial?

The front-end SPA will be built using HTML5, AngularJS, and Twitter Bootstrap. The back-end server will be built using ASP.NET Web API 2 on top of Owin middleware not directly on top of ASP.NET; the reason for doing so that we’ll configure the server to issue OAuth bearer token authentication using Owin middleware too, so setting up everything on the same pipeline is better approach. In addition to this we’ll use ASP.NET Identity system which is built on top of Owin middleware and we’ll use it to register new users and validate their credentials before generating the tokens.

As I mentioned before our back-end API should accept request coming from any origin, not only our front-end, so we’ll be enabling CORS (Cross Origin Resource Sharing) in Web API as well for the OAuth bearer token provider.

Use cases which will be covered in this application:

  • Allow users to signup (register) by providing username and password then store credentials in secure medium.
  • Prevent anonymous users from viewing secured data or secured pages (views).
  • Once the user is logged in successfully, the system should not ask for credentials or re-authentication for the next 24 hours 30 minutes because we are using refresh tokens.

So in this post we’ll cover step by step how to build the back-end API, and on the next post we’ll cover how we’ll build and integrate the SPA with the API.

Enough theories let’s get our hands dirty and start implementing the API!

Building the Back-End API

Step 1: Creating the Web API Project

In this tutorial I’m using Visual Studio 2013 and .Net framework 4.5, you can follow along using Visual Studio 2012 but you need to install Web Tools 2013.1 for VS 2012 by visiting this link.

Now create an empty solution and name it “AngularJSAuthentication” then add new ASP.NET Web application named “AngularJSAuthentication.API”, the selected template for project will be as the image below. Notice that the authentication is set to “No Authentication” taking into consideration that we’ll add this manually.

Web API Project Template

Step 2: Installing the needed NuGet Packages:

Now we need to install the NuGet packages which are needed to setup our Owin server and configure ASP.NET Web API to be hosted within an Owin server, so open NuGet Package Manger Console and type the below:

The  package “Microsoft.Owin.Host.SystemWeb” is used to enable our Owin server to run our API on IIS using ASP.NET request pipeline as eventually we’ll host this API on Microsoft Azure Websites which uses IIS.

Step 3: Add Owin “Startup” Class

Right click on your project then add new class named “Startup”. We’ll visit this class many times and modify it, for now it will contain the code below:

What we’ve implemented above is simple, this class will be fired once our server starts, notice the “assembly” attribute which states which class to fire on start-up. The “Configuration” method accepts parameter of type “IAppBuilder” this parameter will be supplied by the host at run-time. This “app” parameter is an interface which will be used to compose the application for our Owin server.

The “HttpConfiguration” object is used to configure API routes, so we’ll pass this object to method “Register” in “WebApiConfig” class.

Lastly, we’ll pass the “config” object to the extension method “UseWebApi” which will be responsible to wire up ASP.NET Web API to our Owin server pipeline.

Usually the class “WebApiConfig” exists with the templates we’ve selected, if it doesn’t exist then add it under the folder “App_Start”. Below is the code inside it:

Step 4: Delete Global.asax Class

No need to use this class and fire up the Application_Start event after we’ve configured our “Startup” class so feel free to delete it.

Step 5: Add the ASP.NET Identity System

After we’ve configured the Web API, it is time to add the needed NuGet packages to add support for registering and validating user credentials, so open package manager console and add the below NuGet packages:

The first package will add support for ASP.NET Identity Owin, and the second package will add support for using ASP.NET Identity with Entity Framework so we can save users to SQL Server database.

Now we need to add Database context class which will be responsible to communicate with our database, so add new class and name it “AuthContext” then paste the code snippet below:

As you can see this class inherits from “IdentityDbContext” class, you can think about this class as special version of the traditional “DbContext” Class, it will provide all of the Entity Framework code-first mapping and DbSet properties needed to manage the identity tables in SQL Server. You can read more about this class on Scott Allen Blog.

Now we want to add “UserModel” which contains the properties needed to be sent once we register a user, this model is POCO class with some data annotations attributes used for the sake of validating the registration payload request. So under “Models” folder add new class named “UserModel” and paste the code below:

Now we need to add new connection string named “AuthContext” in our Web.Config class, so open you web.config and add the below section:

Step 6: Add Repository class to support ASP.NET Identity System

Now we want to implement two methods needed in our application which they are: “RegisterUser” and “FindUser”, so add new class named “AuthRepository” and paste the code snippet below:

What we’ve implemented above is the following: we are depending on the “UserManager” that provides the domain logic for working with user information. The “UserManager” knows when to hash a password, how and when to validate a user, and how to manage claims. You can read more about ASP.NET Identity System.

Step 7: Add our “Account” Controller

Now it is the time to add our first Web API controller which will be used to register new users, so under file “Controllers” add Empty Web API 2 Controller named “AccountController” and paste the code below:

By looking at the “Register” method you will notice that we’ve configured the endpoint for this method to be “/api/account/register” so any user wants to register into our system must issue HTTP POST request to this URI and the pay load for this request will contain the JSON object as below:

Now you can run your application and issue HTTP POST request to your local URI: “http://localhost:port/api/account/register” or you can try the published API using this end point: if all went fine you will receive HTTP status code 200 and the database specified in connection string will be created automatically and the user will be inserted into table “dbo.AspNetUsers”.

Note: It is very important to send this POST request over HTTPS so the sensitive information get encrypted between the client and the server.

The “GetErrorResult” method is just a helper method which is used to validate the “UserModel” and return the correct HTTP status code if the input data is invalid.

Step 8: Add Secured Orders Controller

Now we want to add another controller to serve our Orders, we’ll assume that this controller will return orders only for Authenticated users, to keep things simple we’ll return static data. So add new controller named “OrdersController” under “Controllers” folder and paste the code below:

Notice how we added the “Authorize” attribute on the method “Get” so if you tried to issue HTTP GET request to the end point “http://localhost:port/api/orders” you will receive HTTP status code 401 unauthorized because the request you send till this moment doesn’t contain valid authorization header. You can check this using this end point:

Step 9: Add support for OAuth Bearer Tokens Generation

Till this moment we didn’t configure our API to use OAuth authentication workflow, to do so open package manager console and install the following NuGet package:

After you install this package open file “Startup” again and call the new method named “ConfigureOAuth” as the first line inside the method “Configuration”, the implemntation for this method as below:

Here we’ve created new instance from class “OAuthAuthorizationServerOptions” and set its option as the below:

  • The path for generating tokens will be as :”http://localhost:port/token”. We’ll see how we will issue HTTP POST request to generate token in the next steps.
  • We’ve specified the expiry for token to be 24 hours, so if the user tried to use the same token for authentication after 24 hours from the issue time, his request will be rejected and HTTP status code 401 is returned.
  • We’ve specified the implementation on how to validate the credentials for users asking for tokens in custom class named “SimpleAuthorizationServerProvider”.

Now we passed this options to the extension method “UseOAuthAuthorizationServer” so we’ll add the authentication middleware to the pipeline.

Step 10: Implement the “SimpleAuthorizationServerProvider” class

Add new folder named “Providers” then add new class named “SimpleAuthorizationServerProvider”, paste the code snippet below:

As you notice this class inherits from class “OAuthAuthorizationServerProvider”, we’ve overridden two methods “ValidateClientAuthentication” and “GrantResourceOwnerCredentials”. The first method is responsible for validating the “Client”, in our case we have only one client so we’ll always return that its validated successfully.

The second method “GrantResourceOwnerCredentials” is responsible to validate the username and password sent to the authorization server’s token endpoint, so we’ll use the “AuthRepository” class we created earlier and call the method “FindUser” to check if the username and password are valid.

If the credentials are valid we’ll create “ClaimsIdentity” class and pass the authentication type to it, in our case “bearer token”, then we’ll add two claims (“sub”,”role”) and those will be included in the signed token. You can add different claims here but the token size will increase for sure.

Now generating the token happens behind the scenes when we call “context.Validated(identity)”.

To allow CORS on the token middleware provider we need to add the header “Access-Control-Allow-Origin” to Owin context, if you forget this, generating the token will fail when you try to call it from your browser. Not that this allows CORS for token middleware provider not for ASP.NET Web API which we’ll add on the next step.

Step 11: Allow CORS for ASP.NET Web API

First of all we need to install the following NuGet package manger, so open package manager console and type:

Now open class “Startup” again and add the highlighted line of code (line 8) to the method “Configuration” as the below:

Step 12: Testing the Back-end API

Assuming that you registered the username “Taiseer” with password “SuperPass” in the step below, we’ll use the same username to generate token, so to test this out open your favorite REST client application in order to issue HTTP requests to generate token for user “Taiseer”. For me I’ll be using PostMan.

Now we’ll issue a POST request to the endpoint the request will be as the image below:

OAuth Token Request

Notice that the content-type and payload type is “x-www-form-urlencoded” so the payload body will be on form (grant_type=password&username=”Taiseer”&password=”SuperPass”). If all is correct you’ll notice that we’ve received signed token on the response.

As well the “grant_type” Indicates the type of grant being presented in exchange for an access token, in our case it is password.

Now we want to use this token to request the secure data using the end point so we’ll issue GET request to the end point and will pass the bearer token in the Authorization header, so for any secure end point we’ve to pass this bearer token along with each request to authenticate the user.

Note: that we are not transferring the username/password as the case of Basic authentication.

The GET request will be as the image below:

Token Get Secure Resource

If all is correct we’ll receive HTTP status 200 along with the secured data in the response body, if you try to change any character with signed token you directly receive HTTP status code 401 unauthorized.

Now our back-end API is ready to be consumed from any front end application or native mobile app.

Update (2014-08-11) Thanks for Attila Hajdrik for forking my repo and updating it to use MongoDb instead of Entity Framework, you can check it here.

You can check the demo application, play with the back-end API for learning purposes (, and check the source code on Github.

Follow me on Twitter @tjoudeh



  1. Long DaGe says

    Am I missing something here? I downloaded the code linked to this article, part 1, and I don’t see the token endpoint in the code?

    In the startup.cs file I see where the endpoint is defined:
    OAuthAuthorizationServerOptions OAuthServerOptions = new OAuthAuthorizationServerOptions()
    //For Dev enviroment only (on production should be AllowInsecureHttp = false)
    AllowInsecureHttp = true,
    TokenEndpointPath = new PathString(“/api/token”),
    AccessTokenExpireTimeSpan = TimeSpan.FromMinutes(30),
    Provider = new CustomOAuthProvider(),
    AccessTokenFormat = new CustomJwtFormat(“”)

    But where is the code to handle this endpoint? Shouldn’t it be in a controller called TokenController?

    When I run this code from this first part, I get an .NET error:
    [ArgumentNullException: Value cannot be null.
    Parameter name: token]

  2. mira says

    Hello taiseer, thank you a lot for this wonderful tuto, i’m using it for creating accounts so i’d like to implement a Policy that force users to change their password at first login, any help ?

      • meriem says

        Ok i should implement it is it a good way to create an attribut in the database that has the stat value so if it’s not yet changed redirect the user to the change password page ? and another question please i wanted to manage roles in the same tuto so i started with implementing it ‘im assuming i can use the resolve in the app.js and implement a function that check if the user has the role, my problm is the code for that function supposing that the role is saved in localstrorage

  3. says


    Thanks for the article, great tutorial so far!

    I have a question: how do I proceed to get the user name in a Controller request from an authorized user?


  4. Scott says

    Hey Taiseer, great tutorial!

    Now if only I could find the same thing, but with an Active Directory as the back-end instead of Identity’s SQL tables. I’m working for a corp. with an AD and don’t need any of the registration bits, just need to make sure the user is in the AD, and that they belong to certain group(s). (Am I correct in assuming that my interaction with the AD would go in the GrantResourceOwnerCredentials() override?)

    Any pointer(s) you can offer would be highly appreciated!

  5. adri says

    Hi Taiseer! You mentioned https to ensure the sensitive information get encrypted between the client and the server during resgistration. What is a good approach for this? Thanks a lot.

  6. says

    Really nice Taiseer. Thanks for sharing. i have implemented successfully in my project its working perfectly fine. but only i am getting issue during filter time my query string become longer because of access token. so is there any way i can generate access token shorter.

      • says

        thanks for reply i am using Restangular , in Restangular i am not getting how to pass access token through authorization header , please give me any link or example so that i can pass access token through authorization header in Restangular.

        • says

          Hi Ravi,
          I didn’t use RestAngular before, but I believe you can configure the HTTP provider to inject a header before firing the request. Better to ask this in StackOverFlow. Thanks

    • says

      Hi Vinicius,
      Sorry for the late reply, well in this method “GrantResourceOwnerCredentials” you need to replace this LOCs with your custom logic to validate username/password, you can use ADO.NET, EF, or any other provider you prefer.
      Hope this help.

  7. Scott Fraley says

    I’d swear I left a comment a couple of days ago asking about how to do this with an AD back-end instead of the AspNetUser (et al) (Identity SQL Tables), but it apparently vanished. :(

    Any thoughts on the above question?

    Thanks (for a great tutorial!),

  8. John M. says

    Let me start by saying thank you for this guide! It helping me to understand the whole process behind token authentication. I just have a question:

    1. If your using EntityFramework, and enables Migrations, how do you seed the database with the configuration.cs (in migration) if you don’t have a ApplicationUser? I’m use to the old wait of building an whole application with WebApi2 + MVC settings (individual authentification) and it’s comes with the ApplicationUser class.

    Normaly, ill do:
    var store = new UserStore(context);
    var userManager = new UserManager(store);
    var user = new ApplicationUser ( Id = “1” , […]);
    userManager.Create(user, “Password”);

    Also, if I want to save more information in the database like firstname and lastname. How can I add those value. I tried in the authRepo but IdentityUser doesn’t have the property and I cant change the value of IdentityUser.

    thank you for your help!

  9. Weerayut Teja says

    This tutorial very clear, after stuck and get a lot of errors in many hours. I stopped at this website with the result i expected!
    Thanks Taiseer! I will continue to read another posts on your blog.

  10. Chris Tan says

    Awesome work Taiseer for writing up this amazing simple tutorial. I have a rather silly question to ask, really hope that you can help me clarify this. What’s the difference between your approach and OAUTH 2.0 implementation? I’ve noticed that some of Google’s API requires ClientID and Client Secret in order to be granted access to their API. Do hope that you can help me to clarify this 😀 thanks!

    • says

      Hi Chris,
      Well, OAuth 2.0 has many flows to support different type of clients (JS apps, native mobile apps, server-side apps), the type of the app determines which flow to use, some of those flows require client id and secret in order to authenticate the app itself. I recommend you to take a look at this startup post to get a better understanding of Oauth 2.0 concepts.

  11. says

    Great tutorial!!! Thanks. I just noticed that if you are using Ninject with the API project you may want to replace WebApiConfig.Register(config); (startup.cs) with GlobalConfiguration.Configure(WebApiConfig.Register); as found in the global which is deleted. This will enable correct registration of the DI container when using webactivatorex.

  12. dancun chiriga says

    hallo and thanks again for this great post!

    Now as a newbie, i dont know how to set my connection string since i want to use an azure database..Please advise me. Regards

  13. says

    I’ve reproduced the code on this article and it seemed to be working fine on my local machine (IIS Express). When I’ve deployed it to a standalone server running IIS6 it’s stopped working.

    When I send a Fiddler POST request to the token endpoint with valid credentials, I get a 400 Bad Request response. The response has an invalid_grant error and that “Login failed for Login failed for user ‘DOMAIN\APPIISDEV$'” which appears to be the server IIS account.

    Any ideas what might be causing this?

    It seems to be failing in the SimpleAuthorizationServerProvider, in the GrantResourceOwnerCredentials method. The OAuthValidateClientAuthenticationContext seems to have the correct username (as supplied by the POST request body), but the request still fails with a 400 Bad Request.

  14. Pieter-Jan says

    I was wondering what the advantages are compared to IdentityServer? I don’t see any implementation here for replay attack (nonce) and some other functionality that is build-in in IdentityServer.

    • says

      This is a very basic implementation if you need to build a simple Api and you do not want a full-fledged Identity Server, think tecture is the way to go for any enterprise application.

  15. says

    After user login the system and got the token, i will save the token in the database. And the user use the token to call other method, how can I got the token manually because i want to use it to compare the token in the database?

    • says

      You should not store the token in DB, there are different ways to store them locally, you can think of a secure cookie. What is your use case to store them in DB?

Leave a Reply