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.
0
1
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.
0
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.
2
@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.
0
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.
0
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.
3
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.
0
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 :-/.
2
JWT jak najbardziej można stosować i stosuje się razem z Identity. Po prostu podmieniasz metodę- zamiast używania ID sesji i cookies używasz JWT- można również wraz z cookie, lub "po Bożemu" przesyłając token w headerze Authorization. Nawet jeśli nie użyjesz Identity do zarządzania użytkownikami to pozwoli Ci to na inne operacje- wbudowane wsparcie dla uwierzytelniania i autoryzacje requestów, zarządzanie rolami czy też coś tak prostego jak automatyczny dostęp do użytkownika (ClaimsPrincipal).
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
To już zależy kto to stosuje :) Ja używam jedno i drugie, bo Identity nie wyklucza JWT ale i nie wymaga, i vice versa. To po prostu zależy od potrzeb.