MVC AD Azure Refresh Token za pośrednictwem ADAL JavaScript Ajax i KnockoutJs

Question

Istnieje nieodłączna wada projektu w typie aplikacji MVC, którą zbudowałem i wierzę, że nie jestem pierwszą osobą, która zdaje sobie z tego sprawę.

Mam MVC 4 Zastosowanie który wykorzystuje AD uwierzytelniania Azure, który został wprowadzony do stosowania w następujący sposób

Developing ASP.NET Apps with Azure Active Directory

Gdy jako użytkownik jest uwierzytelniony i Home.cshtml ładunki, KnockoutJs służy do wykonywania JavaScript AJAX POST i GET żądania odczytu i zapisu danych.

Nie jest to więc dokładnie jedna strona, ale raczej połączenie tradycyjnych postów do uwierzytelniania i udostępniania zasobów oraz operacji odczytu/zapisu za pośrednictwem AJAX.

Podczas żądań AJAX token uwierzytelniania wygasa, a AD nie jest w stanie odświeżyć tokenu za pomocą JavaScript. obserwuje

następujący błąd przeglądarki

XMLHttpRequest nie może załadować https://login.windows.net/xxx. Na żądanym zasobie nie ma nagłówka "Access-Control-Allow-Origin". Pochodzenie 'xxx' jest zatem niedozwolone.

Sprawdziłem adal.js i następujące posty, ale nie jestem pewien, czy adal.js jest rozwiązaniem dla mojego typu aplikacji lub jak najlepiej go włączyć, aby działało z moim typem aplikacji.

Moje rozumienie tej pory:

nie używam angularjs.

Nie zaczynam uwierzytelniania przez JavaScript, a moje uwierzytelnienie nie jest obsługiwane przez JavaScript, aby móc korzystać z adal.js.

Uwierzytelnianie jest wykonywane po stronie serwera, a kolejny mechanizm tokenu odświeżania OAuth2 wymaga pełnego odsyłania stron.

Natknąłem się na różne posty opublikowane przez Vittorio Bertocci, ale żaden nie odnosi się do cech tego typu projektu aplikacji 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

Problem z konfiguracją jest to, że używasz plików cookie do uwierzytelniania AJAX wywołuje. Pliki cookie nie są do tego dobrze przystosowane, a ograniczenia tego podejścia zwykle pojawiają się, gdy musisz dzwonić poza domenę i/lub gdy ciasteczko wygaśnie. Fakt, że jest to wspólne podejście, w dużej mierze jako krok ewolucyjny ze względu na fakt, że właściwe wsparcie SPA dla auth nie było dostępne od jakiegoś czasu, nie czyni tego dobrym podejściem. Możesz swobodnie trzymać się obecnego podejścia, ale spowoduje to pewien ból. Nie ma ustalonego mechanizmu wyzwalania odnawiania sesji z JS.Mimo że może to zostać zhakowane razem, nie mamy na to próbek - głównie dlatego, że jest to hack :) podstawowy przypadek wydaje się dość łatwy, ale zaraz po rozpoczęciu rozważania wszystkich możliwych przypadków (co się stanie, gdy sesja Twojej aplikacji wygasła, użytkownik wylogował się z Azure AD i zalogował się na inne konto?). Najbardziej niezawodnym podejściem byłoby porzucenie podejścia hybrydowego. Jeśli chcesz być aplikacją JS, możesz wyeliminować wszystkie loginy sterowane przez serwer i nadal zachowuj zdolność wykonywania przepływów po stronie serwera (za pośrednictwem dotacji, takich jak https://github.com/AzureADSamples/WebAPI-OnBehalfOf-DotNet). Nie musisz nawet konwertować na kątowe, jeśli nie chcesz, zobacz https://github.com/AzureADSamples/SinglePageApp-jQuery-DotNet. A jeśli chcesz być aplikacją opartą na poczcie zwrotnej, możesz zrzucić część JS (choć brzmi to boleśnie).

TL; DR: zabezpieczanie połączeń AJAX za pomocą plików cookie nie jest rozwiązaniem czystym, a użytkownik odczuwa ból. Twoje wybory to między łataniem problemów z hackami ad hoc lub refaktorem w kierunku bardziej kanonicznego podejścia. Przepraszamy za złe wieści :(