Where is the authentication token stored on the client side?

Question

I want to host an MVC 4 Web API project on Azure. I need to make sure the APIs can be accessed from any third-party app and any browser. Implementing a RESTful API that simply returns JSON sounds like a good idea to me. Now, the biggest challenge to me is creating a platform-agnostic authentication mechanism. I don't want to use the default MembershipProvider. I'll be using SSL. I also won't use FormsAuthentication. All API calls are going to be through JQuery/AJAX.

I'm trying to understand token-based authentication. Here's what I thought I could do: - Client sends their user credentials to the server over HTTPS - Server authenticates the client, creates a token, saves it to the DB along with a date-time stamp and expiration period, and sends it back to the client - Client sends the token to the server every time they access an API

Now, the part I don't understand is, where does the client store the token? Is it saved in a cookie? If so, where do non-browser third party apps save the authentication token? How easily is the token stolen?

Answer 1

The authentication token is stored in cookie by the ASP.net membership provider and authentication module. On the client side the HTTP client library can deal with cookies. The cookieless authentication is also possible with forms authentication. If the channel is not encrypted(ssl or https) then the token can be stolen by the middle man sniffers. Secure websapps sets a small timeout for the authentication cookie so that a small period of inactivity will expire the session thus the cookie.

However for API authentication the authentication mechanism can be different. Each call can be independently authenticated. So there is no need to maintain a token for the client. The Authorization header for each API call should have some secret that server can identify. Amazon AWS uses this style of API authentication and many other followed this style. With webapi you can implement this kind of authentication.

1. The client has a private key for his account issued by the server or imported into the server for the account by the user.

2.The client calls the API as usual but puts some information into the Authorization header. The information would be HMAC of data being send mixed with account id of the client and the date.

Here is how the authorization header in HTTP API should look like

Authorization: account-id  HMAC_OF_WITH_SECRET_KEY(data + account-id + GMT Date that will be in date header)

3.On the server side( WebApi side )you need have custom AuthorizeAttribute for the WebApi controllers. These custom authentication will receive the requests from client and do reverse of what client has done. The server has client private key and it can arrange the data as client has done and again calculate the HMAC. If this HMAC is same as that of what is send in Authorization header then it is authenticate client for the account or user id. Note that the authorization header has the account-id + HMAC secret. So using the account-id or user-id in this header server can know which client is requesting.

This mechanism covers authentication as well as data integrity.