Web UI: Resource Guarding and Login

HTTP Redirects

In order to share some insights with others, I would like to comment on the subject of HTTP redirection in web applications for handling unauthenticated requests by redirecting users to a login page.

First of all, a quick introduction to HTTP redirection is in order. On the surface, HTTP redirection is a very simple mechanism for rerouting the original client request to a different web resource than that, which was requested. The term rerouting here is a tricky one. It might be thought of as if the server simply passes on the original request to a different web resource. However, the mechanism is a lot more intricate -- it involves both the server and the client, and in most cases the original request is not simply forwarded to a different URI, but a completely new request gets constructed instead.

Here is how it works. The client sends a request to a server. The server decides to redirect the request. For this to happen, the server responds to the client with HTTP code 30x (in most cases 301 or 302, more on that later) and header Locator pointing to a URI where the client (not the request per se!) should be redirected. The client is expected to recognise the response, and automatically (in most case, without user even noticing it) issue a new request to the specified by server URI.

The new request, issued by the client to the redirected URI, may have different HTTP method and may not carry the same payload as the original request. In fact, modern web browsers handle HTTP redirection codes 301, 302 and 303 by always specifying method GET that cannot have any payload by its design. Only HTTP code 307 promises to reproduce the original request (e.g. POST with relevant payload), but the specification requires web browsers to produce a scary confirmation dialog to the user requesting permission to proceed. The reason for this is quite understanding, as redirecting POST request may actually lead to potential information leaking. Therefore, the most sensible approach is to always use codes 301 or 302. The first code specifies a permanent redirect, indicating that the previously references by the specified URI resource has been relocated permanently to a new URI. This allows search crawlers update their references. The second code indicates a temporary relocation of the requested resource, with a promise to return to its original location referenced by the specified in the original request URI.

Is HTTP redirection to a Login page a good idea?

At first it seems to be a very logical thing to do -- implement HTTP redirection to a login page as part of a server side resource authentication mechanism (aka a web resource guard). Many web sites take this approach. Indeed, such a guard could verify authenticity of a HTTP request and, in case of a negative result, would simply redirect the original request to a login page. The user would immediately understand that a login is required, log in, and could even be automatically taken to the originally requested resource (if such functionality is provisioned for).

However, after thinking how such guard would be implemented and tested, it was realised that some SOLID principles would get violated if an automatic redirection to a login page is to be supported. For example, a single responsibility principle would get violated because the guard would need to be responsible for HTTP request authentication as well as for HTTP request redirection. This also brings up some security concerns as discussed further.

An alternative approach, which is especially well suited for SPA (Single Page Application), is for the guard to be responsible strictly for HTTP request authentication only. In case of unsuccessful request authentication, the guard would respond with HTTP code 403 (Forbidden), indicating to the client that no credentials where provided to access the requested resource. Then it is up to client side application to decide what needs to be done with such response. For example, a SPA could automatically send a request to load a login page or redirect the user to a standard for the application "resource access forbidden" landing page.

This approach has two immediate benefits:

1. It helps to further harden the application security by simply denying random requests from potential adversaries without providing them with a knowledge of a login page. The login page could be their next logical step at an attempt to break into the system by picking up user names and passwords.

2. The resource guard implementation would have a single easy to unit test responsibility.

There are of course disadvantages. If a user receives a link from one of co-workers to a certain application web resource (e.g. a specific dashboard) then it would require two steps to open this link in case where application is being accessed from a device without an active session. For trusted devices this would not cause any issues. For untrusted devices with a short session timeframe, the user may need to login explicitly (first step) and then try to load the web resource. This, however, is a small price for a better security, and would not affect users under normal circumstances (i.e. accessing the application from trusted devices).