Token Authentication with Sitecore and WebApi

Recently, I was tasked with developing the back-end of a Single page application. The application needed authorization for different types of users, and there was an emphasis on being able to run automated tests against the endpoints. The project used Sitecore as CMS, and we needed authorization against our own WebApi endpoints.

I decided to implement bearer token authentication, since it should make it easy to implement automated endpoint testing (every request contains everything needed, and we avoid cookies). Looking around a bit to see if there was an easy way to do this, I found this blog post: http://www.coreblimeysitecore.com/blog/token-based-authentication-with-sitecore-services-client/

This showed me that Sitecore already has some support for token authentication built in. Now I just needed my WebApi endpoints to support using this as well. Awesome!

First step of token authentication should be to issue a token. Now, there might be all kinds of custom logic in your login controller. But for our example we will just validate the domain, username and password. If they are valid, we will create a token containing only the username. On Requests for our API endpoints, we validate the token and if the token is valid, we log the user into Sitecore using the username. Remember, the token is signed using a secret key that only we know. So if we can validate the token, we have issued it. The validation is done in the pipeline, before the endpoint is actually invoked. This means that our controller endpoints will be able to access all the normal Sitecore authentication features. At the end of the response cycle, we remove all cookies, so we don’t get any of the hazzle of dealing with cookies on our endpoints (only for our endpoints).

Enough talk! Let’s have a look at some code. First of all, you can find the repository here: https://github.com/chrsin/sctokenauth. Sadly, Medium is terrible at displaying code, so I’ll have to describe it without the code. First, let’s have a look at how all of this is set up. If we look in the App_Config folder of the git repository, we see the ConnectionStrings.config file. It just contains the key for the TokenProvider. So, you just need to add this connection string entry to your own connection strings (and obviously change the key to something else).

Under the App_Config\Include folder we have Mvc.config. This registers the WebApiSetup which in turn registers the AuthorizationException handler and the CookieRemover filter to the WebApi configuration.

The TokenAuth.config file registers everything needed for our TokenAuth.

First of all, it contains settings for enabling the token authentication in Sitecore (described in the coreblimey link). It also registers the TokenAuthUserResolver in the httpRequestBegin pipeline. The TokenAuthUserResolver is responsible for logging the user in to Sitecore, if a valid token is supplied for the request.
Let’s have a look at the TokenAuthUserResolver.

First of all, we ignore requests where the user is already logged in. After that there is some logic for parsing the token from the Authorization header, and then we use the ITokenProvider to validate that the token is valid. If the token is valid, we log the user in to Sitecore using the username from the token.

Remember, I mentioned that we remove the cookies from the response? When the Sitecore pipeline is invoked, some cookies are automatically set which we don’t want for our API endpoints. This is where the RemoveCookiesFilterAttribute comes into play.

Basically, we check the controller for our MyWebsite namespace, and if it starts with our namespace, we clear the cookies from the response. This way we make sure to avoid trashing anything Sitecore might be expecting on their own endpoints.

Lastly, let’s have a look at a controller using our newly implemented logic.
The SimpleLogin action issues a token if the credentials are valid. The IUserService.Login method throws an AuthenticationException on invalid credentials (which we handle in an exception filter).

In the GetTime action we throw an AuthorizationException if the user is the anonymous Sitecore user. Otherwise, we returned the result of this method. It’s that simple! The reason I don’t use the WebApi Authorization attributes on my actions is that I like to unit test that my endpoints are Authorized. Hope you enjoyed this, and it can help you like it did on my project.