How to handle not authenticated Ajax requests with a web authentication service

Whether your are a software developer in an internal IT department or a programmer in a small software development shop - new applications primarily target the web. A couple of weeks ago you finished a custom CRM web site. While creating your second web application - a warehouse reporting system - you soon will find that there are some commonalities between those apps.

One of those commonalities is authentication and authorisation. Nearly every web application needs that - it's a so called cross cutting concern. In times of service oriented architectures (SOA) and obeying good software engineering practices like DRY, you came up with the idea of writing your own authentication service. And you already have a name for it: Simple Authentication Service (SAS).

Hey, this is a great idea. And if Google does that, you will be able to pull that off too. Weather you like it or not: if you log in to GMail, you will be authorized to access other Google services like Google Drive, Google Calendar and Google Contacts too. As depicted in the screenshot below, these applications are just a mouse click away.

Advantages of a central authentication service

At Xaidat we develop various web applications and decided to roll out our own central authentication service as well. We believe in numerous advantages of a central authentication service:

• Authentication code is written once - and used everywhere
• Bug fixing and new feature development is done in one single place
• User interface components like a 'log in' and 'Forgot my password' page are shared amongst applications
• Users sign in to one application and are authenticated to other web applications automatically 
• Users do not have to remember multiple accounts

The basic architecture of a form based authentication service

There exist several authentication types in web application security:

• HTTP Basic Authentication
• HTTP Digest Authentication
• HTTPS Client Authentication
• Form Based Authentication

All of those authentication types have pros and cons. However, in this article we focus on Form Based Authentication. Regardless of the concrete server-side technology, be it Java, .NET or even PHP, basically you want to implement something like this:
Form Based Authentication means that when a user successfully logged in, a session identifier is stored as a cookie in the user's browser. As long as this cookie is valid, each HTTP request to the same URL the cookie originated from is signed with this auth-cookie. We won't go into detail how to process this auth-cookie on the server. Every modern web application environment should support Form Based Authentication in some way.

If the Form Based Authentication mechanism recognizes a not authenticated user, the user should be forwarded to a log in page. To give an example, say an HTTP request approaches for the URL http://www.yourapp.com/admin. The sent auth-cookie is either missing or no longer valid (e.g. due to a session timeout). Consequently the server won't respond with the requested resource, but will sent an HTTP redirect with status code 302 and a response header named location pointing to http://sas.yourcompany.com/login. The users browser recognizes HTTP status code 302 and will transparently redirect the user to http://sas.yourcompany.com/login. The user enters his credentials, hits the submit button and a HTTP request is sent to your SAS service. The SAS service then processes the authentication process. If the authentication was successful, SAS responds with HTTP 302 with the response header 'location' set to the initially requested URL, namely http://www.yourapp.com/admin. Here is screenshot of Firebug showing the HTTP redirection.

Pro Tip: if you are in a Java shop and feel comfortable with Spring, we recommend using Spring MVC in conjunction with Spring Security. Spring Security is a well established security framework heavily used in the industry. It allows to decorate Spring MVC Controller methods with authentication and authorisation annotations. Moreover a central configuration file allows to define general security constraints for the URLs of your web application.

Authentication of Ajax requests

You implemented your own SAS and already integrated it in two web applications. Developing SAS was an upfront investment but it will save you precious development time in future projects. With SAS in your toolbox, you can now concentrate on more fancy stuff, i.e. adding some cool on-page interactivity stuff. There Ajax is the name of the game and with the widely used jQuery framework this should be a breeze. You've even implemented long-polling so that events trickle in the web application as they happen - without requiring the user to refresh the browser. But one day your boss will approach you saying "I was able to do stuff on your web application although I was logged out. This seems to be a serious security issue and we need to fix this!" It turns out that your boss had opened your web application in separate tabs in the same browser. He logged out in the first tab and came back to the second tab. While the session is set invalid, your boss was not redirected to the log in page.

You think this is an easy one: the client-side code in the browser has to be slightly adapted. You add a global jQuery ajaxComplete handler which is checking for HTTP 302 and in case redirects the browser to the log in page. At least numerous posts on stackoverflow, likes this one, tell you to do so.

But it just doesn't work. You've already wasted several hours in Firebug analyzing the HTTP traffic. You even started to debug jQuery to find out why the HTTP 302 response is not executed by the browser.

Congratulations, you've fallen into the 'same origin policy'-trap. Because your application is hosted on http://www.yourapp.com/admin and your SAS runs on http://sas.yourcompany.com, the XmlHttpRequest will not process redirects. See this piece of the official W3C specification:

Two origins are said to be the same origin if the following algorithm returns true:

1. Let A be the first origin being compared, and B be the second origin being compared.
2. If A and B are both opaque identifiers, and their value is equal, then return true.
3. Otherwise, if either A or B or both are opaque identifiers, return false.
4. If A and B have scheme components that are not identical, return false.
5. If A and B have host components that are not identical, return false.
6. If A and B have port components that are not identical, return false.
7. If either A or B have additional data, but that data is not identical for both, return false.
8. Return true.

 

Authentication of Ajax requests

To handle authentication of Ajax requests across origins, both server and client-side code has to be modified.

The server-side

On the server-side Ajax requests need to be handled separately. Ajax requests are recognizable by a special request-header with the name X-Requested-With set to the value XMLHttpRequest. If this header is detected on server-side, the server sends a response with a custom, not standardized HTTP status code, say 333. In addition a response-header is attached (e.g. X-Location) which holds the referer request-header. Xaidat's authentication service uses Spring Security. Here is an exemplary code snippet of the implemented AuthenticationEntryPoint interface:

The client-side

On the client-side the global jQuery ajaxComplete handler needs to check status code 333. If the status code is detected, the browser's URL is set to the location that comes with the response-header location. Here is an example of the client-side handler.


Xaidat is an Austrian software company focusing on web technologies and has successfully developed numerous web applications, amongst others its own Simple Authentication Service. You would like to implement your own authentication service and need assistance? Feel free to contact us.