Asp.Net Identity a JWT - razem czy osobno

Cześć,
zacząłem od jakiegoś czasu zgłębiać kwestie web api oraz bezpieczeństwa jako takiego i chciałem się zapytać czy w praktyce stosuje się asp.net Identity razem z JWT czy bardziej albo jedno albo drugie?
Po zalogowaniu się użytkownik otrzymuje token, który zawiera informacje do jakich zasobów ma dostęp. Tak więc wydaje mi się, że proces samego logowania może być stosunkowo prosty (podanie loginu i hasła i porównanie ich z tym co jest w bazie a następnie generacja tokenu i przekazanie go użytkownikowi).
Czy są jakieś dodatkowe korzyści ze stosowania Identity razem z JWT?
Z góry dziękuję za waszą pomoc w rozwiązaniu moich wątpliwości.

JWT jest wykorzystywane w SPA, np. ASP.NET Core + Angular. Wtedy Identity Core generuje token który SPA wykorzystuje.

Wydaje mi się, że nie ma sensu wykorzystywania Identity + JWT, jeśli nie chcesz zalogować użytkownika w SPA, a jedynie w ASP.NET Core.

Dodam, że Identity ma wbudowane role, więc jak masz apke MVC, to Identity będzie wygodniejsze w użyciu i jak dobrze pamiętam bezpieczniejsze.

@bakunet: Przepraszam bardzo kolego, ale co ma wspólnego JWT z SPA? Jeśli front nie będzie SPA to już nie mogę autoryzować przy użyciu JWT? Jeśli pisze aplikację mobilną to z tokenu też nie mogę skorzystać? Jak kolega wyżej napisał Identity można wykorzystać również do zarządzania hasłami, rolami, użytkownikami.

bakunet napisał(a):

JWT jest wykorzystywane w SPA, np. ASP.NET Core + Angular. Wtedy Identity Core generuje token który SPA wykorzystuje.

Wydaje mi się, że nie ma sensu wykorzystywania Identity + JWT, jeśli nie chcesz zalogować użytkownika w SPA, a jedynie w ASP.NET Core.

Prawdopodobnie chciałeś dać rozgraniczenie pomiędzy wykonywaniem widoku client-side / server-side, ale nie wiem tego na pewno.

Rzeczywiście bezpieczne client-side podnosi poprzeczkę. W apkach server-side (o ile nie jakieś cloudy / farmy) to bywa(ło) prostsze.

Orydek napisał(a):

@bakunet: Przepraszam bardzo kolego, ale co ma wspólnego JWT z SPA? Jeśli front nie będzie SPA to już nie mogę autoryzować przy użyciu JWT? Jeśli pisze aplikację mobilną to z tokenu też nie mogę skorzystać?

Nie wiem, nigdy nie korzystałem z JWT w takim środowisku, podejrzewam że też można. Podałem przykład gdzie wg mnie JWT ma sens.

Wydaje mi się, że dużo w tym temacie nieścisłości, więc postaram się sprostować, ale oczywiście mogę się mylić

Domyślnie ASP .NET Core Identity korzysta z uwierzytelnienia opartego o Cookie, czyli po zalogowaniu backend mówi przeglądarce w nagłówkach responsa że ma utworzyć cookie

następnie przeglądarka dołącza(w zależności od ustawień SameSitePolicy) do żądań HTTP wysyłanych do serwera cookiesy.

A zatem, jeżeli przeglądarka dodaje te cookie, to doda je również do żądań HTTP wysłanych z poziomu JSa - nawet bez frameworku SPA :)

Aha, czyli na mobilce lub z desktopa muszę użyć JWT, bo tam mi nic nie podepnie ciastka jak w przypadku przeglądarki?

No nie, bo też sam możesz podpiąć sobie cookie wysyłając request np.

var cookie_value = "CfDJ........";
var client = new RestClient("https://localhost:5001");
var request = new RestRequest("/home/Test", Method.GET);
request.AddCookie("xd_auth", cookie_value);
var response = client.Get(request);
Console.WriteLine(response.Content);

Response

is authenticated xddd?True

Niemniej jednak JWT oferuje jeszcze refresh token, który może być użyty do poprawienia wygody usera, aby się nie musiał się ponownie logować. Nie wiem jak to się robi na cookiesach/sesjach.

Skąd wziąć cookie na mobilce? bo normalnie to przecież w jsonie dostaje tokena i elo

Przy zalogowaniu tak samo jak w przypadku przeglądarki serwer Ci zwróci cookie (albo raczej powie że masz utworzyć takie cookie :))

var client = new RestClient("https://localhost:5001");

var requestLogin = new RestRequest("/home/Login", Method.GET);
var cookie = client.Get(requestLogin).Cookies[0];

var requestSecret= new RestRequest("/home/Test", Method.GET);
requestSecret.AddCookie("xd_auth", cookie.Value);

Console.WriteLine(client.Get(requestSecret).Content);

Czy powinieneś tak to robić? nie wiem, wątpię.

Podatności Cookie?
m.in CSRF

Podatności JWT?
m.in XSS jeżeli jest przechowywany w miejscu do którego JS ma dostęp*

która z tych dwóch podatności jest łatwiejsza w załataniu? moim zdaniem CSRF.

* Teraz akurat znalazłem artykuł w którym ktoś zaleca

The JWT needs to be stored inside an httpOnly cookie, a special kind of cookie that’s only sent in HTTP requests to the server, and it’s never accessible (both for reading or writing) from JavaScript running in the browser.

I to ma sens, ale to po co wtedy JWT jeżeli i tak wszystko lata cookiesem?

Jaką zaletę mają JWT ponad Cookie?

JWT sprawdzają się jeżeli chodzi o cross-server authentication (chociaż niektórzy to nazywają cross-realm auth) np. będąc na A.com logujesz się do B.com. Z tego co wiem nie jest to do zrobienia standardowymi rozwiązaniami przy użyciu Cookie auth bo A.com nie może utworzyć cookie na B.com, gdzie JWT może zostać podpisane przez A.com który zna sekret B.com

Overall, to i tak powinno nie być istotne, bo to ogarniać powinien authorization middleware.

Dziękuję wszystkim za udział w dyskusji.
Czyli tak reasumując, czy w praktyce, w aplikacja typu SPA / WEB API, wykorzystuje się jedno i drugie zabezpieczenie czy raczej albo jedno albo drugie? Bo przyznam, że trochę się pogubiłem :-/.