REST Service custom authentication token

Question

I wanna create custom authentication mechanism for my web API (without 3rd party library as owin, oauth etc..).

How can I develope it? I inspect a couple of post about web API authentication scenario but I confused too.

According my scenario; an user request to web service, firstly the service check token and UDID detail if has not these bot values, user force authentication, if user authenticate service returns a token for this UDID.

As you can see above scenario, what is best practice and true way for developing token based rest service.

Answer 1

In fact, you can consider several approaches according to what you want to support and the security level. Keep in mind that REST mis stateless and you shouldn't keep an authentication state on the server side. This means that you should for each call provide the authentication hints and authenticate the user that makes the request.

Here are the possible approaches:

• HTTP provides a basic authentication. You can provide the username / password encoded with Base 64 within the HTTP header Authorization. Before executing the request, the server application gets the authorization hints and checks them using the hints of the backend (i.e. things match or not)

• In fact the basic authentication is unsurprisingly basic ;-) I mean the password / secret key is always sent in the request. The password / secret key is easily readable since the content of the header Authorization is encoded with Base64 and the secret token is always valid. There is no built-in support for validation and expiration. To go further, you can use temporary tokens. For this, your RESTful application needs to provide two additional resources:

  • The first one allows to get a temporary token based on the authentication hints (username, password). This token has an expiration date and will be used when executing the actual request. This resource commonly also returns a refresh token to get a new one when expired. This prevents from sending again username / password (they are only send once the very first time).
  • The second one gets a new temporary token when a previous one expired based on a refresh token.

• The last level consists in adding request signing to the second approach when actually executing request. This will be done on the client side when executing the request.

For the two last ones, OAuth2 can be the solution since it provides a standard on the way to design / implement such approaches. You can notice that you don't have to use a third-part library to do that.

I recently wrote a blog entry describing in more details such approaches. See this link http://templth.wordpress.com/2015/01/05/implementing-authentication-with-tokens-for-restful-applications/.

Hope that helps. Thierry