MVC AD Azure Update Token via ADAL JavaScript Ajax and KnockoutJs

Question

There is a built-in design flaw in the type of MVC application I created, and I believe that I am not the first to understand it.

I have an MVC 4 application that uses AD Azure Authentication, which was introduced into the application as follows.

ASP.NET Application Development with Azure Active Directory

Once the user authenticates and Home.cshtml loads, KnockoutJs is used to execute JavaScript AJAX POST and GET requests to read and write data.

So it's not exactly a one-page application, but rather a combination of traditional postbacks for authenticating and servicing assets and read / write operations through AJAX.

During AJAX requests, the authentication token expires and AD cannot update the token through JavaScript.

The following browser error is observed

XMLHttpRequest cannot load https://login.windows.net/xxx . The requested resource does not have an Access-Control-Allow-Origin header. Therefore, Origin 'xxx' does not have access.

I studied adal.js and the following posts, but not sure if adal.js is a solution for my type of application or how best to enable it so that it works with my type of application.

My understanding so far:

I do not use AngularJS.

I am not starting authentication with JavaScript, and I am not authenticated with JavaScript to be able to use adal.js.

Authentication is done on the server side, and the subsequent OAuth2 update token mechanism requires full-text postbacks.

I stumbled upon various released posts from Vittorio Bertocci, but no one addresses the design features of this type of MVC application design.

ADAL, Windows Azure AD, and multi-resource token updates

WAAD does not update access token from javascript

Combination of ADAL.Net and ADAL.js

AngularJS + ADAL.JS sets the resource identifier (Audience)

Answer 1

The setup problem is that you use cookies to authenticate AJAX calls. Cookies are not very suitable for this, and the limitations of this approach usually arise when you need to make calls outside your domain and / or when the cookie expires. The fact that this is a general approach, much like an evolutionary step due to the fact that proper SPA support for auth has not been available for some time, does not make it a good approach. You can stick to your current approach, but it can cause some pain. There is no established mechanism for triggering a session cookie update from JS. Although this can be hacked together, we don’t have samples for this - mainly because it’s hacked :) the main case seems simple enough, but as soon as you start considering all the possible cases (what happens if your application session timed out , did the user sign up with Azure AD and sign up with a different account?). The most reliable approach is to abandon the hybrid approach. If you want to be a JS application, you can exclude all server-driven input and retain the ability to execute streams on the server side (via onbehalf grants, for example https://github.com/AzureADSamples/WebAPI-OnBehalfOf-DotNet ). You don't even need to convert to angular if you don't want this, see https://github.com/AzureADSamples/SinglePageApp-jQuery-DotNet . And if you want to become a mail application, you can remove the JS part (although it sounds painful).

TL; DR: Protecting AJAX calls through cookies is not a clean solution, and you will definitely feel some pain. Your choice is to fix problems using ad hoc hacks or refactor towards a more canonical approach. Sorry for the bad news :(