[SPA/Security] SPA i zalogowanie użytkownika na serwerze

Ostatnio się zastanawiałem, czy jeśli piszę SPA, która pobiera z serwera dane uwierzytelnienia dla użytkownika, czy istnieją jakieś przesłanki za tym, żeby autentykacja została wykonana także na serwerze? Zakładając, że weryfikacja użytkownika i tak już następuje w każdym zabezpieczonym endpoincie przy użyciu tokena.

Osobiście nie udało mi się znaleźć solidnego powodu ku temu, aczkolwiek co jakiś czas "wpadam" na projekt który to robi. Co Wy o tym myślicie? Należy też zalogować użytkownika w back-endzie?

Nie rozumiem co masz na myśli. Nie rozumiem czym dla ciebie różni się następuje w każdym zabezpieczonym endpoincie przy użyciu tokena od autentykacja wykonana także na serwerze
Przecież dostajesz token do backendu więc masz zalogowanego usera. W czym rzecz? o_O Czy chodzi ci o to, że niektóre endpointy wymagają authentication a mimo to pewne akcje logiki domenowej wymagają dodatkowo authorization? To przecież bierzesz usera z tokena który dostałeś i sprawdzasz czy moze wykonać daną akcje.

Przykład z życia wzięty:
Mam funkcje systemu która pozwala pobrać podaną listę plików w postaci jednego zbiorczego ZIPa.
Żeby dostać do endpointu wymagane jest authentication i oczekuje ze dostane token.
Mimo wszystko nie wszystkie pliki są dostępne dla każdego, więc przed włożeniem pliku do ZIPa, musze sprawdzić czy użytkownik który wykonuje tą akcje ma dostęp do konkretnego pliku (authorization).

A gdzie teraz robisz "autentykacje"?

Autentykacja to potwierdzenie "tożsamości", czyli np. logowanie.
Autoryzacja to stwierdzenie czy możesz uzyskać dostęp do jakiegoś zasobu, czyli np. ustawienie uprawnień dla użytkowników / grup.

Shalom napisał(a):

Nie rozumiem co masz na myśli. (...)

Korzystając z JWT:

Pinek napisał(a):

JTW ogólnie jest bezstanowy. Także, co ciekawe, nawet jak "wylogujesz" usera z aplikacji i nie będzie mieć sesji, to jeśli ma jeszcze JWT i jeszcze ten token nie wygasł, to nadal będzie mógł uderzać do zabezpieczonego API.

Więc można zalogować usera w SPA (Angular):
public setAuth(auth: LoginResponse | null): boolean

I jednocześnie na serwerze (ASP.NET Core):
var signInResult = await _signInManager.CheckPasswordSignInAsync(user, input.Password, false);

@bakunet

Jeśli ktoś loguje się na serwerze (autentykacja), na nim jest trzymana sesja i przez nią jest autoryzowany, a zasadniczo przez token ID sesji.
Jeśli ktoś otrzymał token to znaczy że został już w jakiś sposób zautentykowany i jego dostęp jest autoryzowany za pomocą tokenu.

Jaki cel ma robienie obydwu rzeczy? Wydaje mi się że jedna z tych dróg jest wystarczająca.

Wydaje mi się że coś tu jest nie tak

Gdy twoje uwierzytelnienie korzysta z JWT, to podczas wysłania go w headerze requesta do endpointa z [Authorize] wykonywane jest "przeliczenie" na podstawie zawartości jsona, algorytmu oraz twojego secret. Jeżeli dla podanych danych i twojego secreta wyjdzie ten sam JWT, co został wysłany, to jest ok.

Tutaj można się pobawić: https://jwt.io

I to się dzieje na serwerze, serwer jest świadomy czy ktoś jest uwierzytelniony czy nie, a dodatkowo w Claimsach są zawarte różne informacje typu Id usera pozwalające go zidentyfikować.

var signInResult = await _signInManager.CheckPasswordSignInAsync(user, input.Password, false);

Dziwi mnie to, bo czy przypadkiem Identity nie realizuje uwierzytelnienia za pomocą Cookie? (nie spotkałem aby było to robione inaczej z Identity)

Jeżeli się gdzieś pomyliłem to poprawcie.