MVC AD Azure Aggiorna token tramite ADAL JavaScript Ajax e KnockoutJs

Question

Esiste un difetto di progettazione intrinseco nel tipo di applicazione MVC che ho creato e credo di non essere il primo a realizzare.

Ho un MVC 4 Applicazione che utilizza AD Azure di autenticazione che è stato introdotto per l'applicazione nel modo seguente

Developing ASP.NET Apps with Azure Active Directory

volta come utente è autenticato e Home.cshtml carichi, KnockoutJs viene utilizzato per eseguire JavaScript AJAX Richieste POST e GET per leggere e scrivere dati.

Quindi non esattamente una singola app di pagina, ma piuttosto un mix di postback tradizionali per le risorse di autenticazione e di servizio e operazioni di lettura/scrittura tramite AJAX.

Durante le richieste AJAX, il token di autenticazione scade e AD non è in grado di aggiornare il token tramite JavaScript. si osserva

il seguente errore del browser

XMLHttpRequest non può caricare https://login.windows.net/xxx. Nessuna intestazione 'Access-Control-Allow-Origin' è presente sulla risorsa richiesta. L'origine 'xxx' non è quindi consentita l'accesso.

Ho ricercato adal.js e nei seguenti post ma non sono sicuro se adal.js sia la soluzione al mio tipo di applicazione o il modo migliore per incorporarlo per farlo funzionare con il mio tipo di applicazione.

mia comprensione finora:

non sto usando AngularJS.

Non avvio l'autenticazione tramite JavaScript e la mia autenticazione non è guidata da JavaScript per poter trarre vantaggio da adal.js.

L'autenticazione viene eseguita sul lato server e il successivo meccanismo di aggiornamento dei token OAuth2 richiede i postback di pagine complete.

Sono inciampato in vari post relitti di Vittorio Bertocci, ma nessuno affronta le particolarità di questo tipo di progettazione dell'applicazione MVC.

ADAL, Windows Azure AD and Multi-Resource Refresh Tokens

WAAD doesn't refresh access token from javascript

Combining ADAL.Net and ADAL.js

AngularJS + ADAL.JS set Resource ID (Audience)

Answer 1

Il problema con la configurazione è che si sta utilizzando i cookie per l'autenticazione chiamate AJAX. I cookie non sono proprio adatti per questo, e i limiti dell'approccio di solito emergono quando devi effettuare chiamate al di fuori del tuo dominio e/o quando il cookie scade. Il fatto che si tratti di un approccio comune, in gran parte come un passo evolutivo dovuto al fatto che il corretto supporto SPA per l'autenticazione non era disponibile da un po 'di tempo, non lo rende un buon approccio. Sei libero di seguire il tuo approccio attuale, ma ciò causerà un po 'di dolore. Non esiste un meccanismo stabilito per l'attivazione di un cookie di sessione rinnovato da JS.Anche se questo può essere hackerato insieme, non abbiamo campioni per questo - principalmente perché è un hack :) il caso base sembra abbastanza facile, ma non appena inizi a considerare tutti i possibili casi (cosa succede se mentre la tua sessione di app è scaduta, l'utente si è disconnesso da Azure AD e ha effettuato l'accesso con un altro account?). L'approccio più infallibile sarebbe quello di abbandonare l'approccio ibrido. Se si desidera essere un'app JS, è possibile eliminare tutti gli accessi guidati dal server e mantenere la capacità di eseguire flussi lato server (tramite sovvenzioni, ad esempio https://github.com/AzureADSamples/WebAPI-OnBehalfOf-DotNet). Non hai nemmeno bisogno di convertire in angolare se non vuoi, vedi https://github.com/AzureADSamples/SinglePageApp-jQuery-DotNet. E se vuoi essere un'app basata su postback, puoi lasciare la parte JS (anche se sembra dolorosa).

TL; DR: proteggere le chiamate AJAX tramite i cookie non è una soluzione pulita e sei destinato a provare dolore. Le tue scelte sono tra aggiustare i problemi con hack ad hoc, o refactoring verso un approccio più canonico. Scusa per le cattive notizie :(