Albo nie znam tego, albo nie za bardzo rozumiem co masz na myśli. Czy poprzez "resource server" rozumiesz po prostu Web API do którego wysyłamy requesty związane z naszą aplikacją? Np. [POST] /invoices? Jeśli tak, to zależy całkowicie od implementacji i skali konkretnej aplikacji. Jeśli masz mała aplikację monolityczną, i tak korzystasz z tokenów JWT, to będziesz to wszystko miał w jednym miejscu. Nie orientuję się żeby OAuth2 miało tu cokolwiek do rzeczy. Mogę się oczywiście mylić, więc chętnie się dowiem więcej. Dla czego tak uważasz?
Tak, Resource Server to API zabezpieczone JWT, a Authorization Server to API/apka generująca te tokeny.
Swoją teorię bazowałem na doświadczeniach/poglądowych schematach OAuth i odpowiedziach na stacku :P Ale to chyba rzeczywiście trochę zbyt daleko idąca teoria.
W RFC dotyczącym OAutha pojawiają się takie stwierdzenia:
The authorization server may be the same server as the resource server or a separate entity.
Ale też:
Unlike access tokens, refresh tokens are intended for use only with authorization servers and are never sent to resource servers.
Schematy przepływów OAuth zazwyczaj pokazują Authorization Server jako oddzielny byt, ale wychodzi na to, że to szczegół implementacyjny.
+--------+ +---------------+
| |--(A)------- Authorization Grant --------->| |
| | | |
| |<-(B)----------- Access Token -------------| |
| | & Refresh Token | |
| | | |
| | +----------+ | |
| |--(C)---- Access Token ---->| | | |
| | | | | |
| |<-(D)- Protected Resource --| Resource | | Authorization |
| Client | | Server | | Server |
| |--(E)---- Access Token ---->| | | |
| | | | | |
| |<-(F)- Invalid Token Error -| | | |
| | +----------+ | |
| | | |
| |--(G)----------- Refresh Token ----------->| |
| | | |
| |<-(H)----------- Access Token -------------| |
+--------+ & Optional Refresh Token +---------------+
To tak naprawdę oddzielny temat od tego o co pyta OP. Oczywiście, często jest tak że cookie authentication wystarczy. JWT mają dodatkowe zalety takie jak to że problem CSRF nie występuje jeśli wysyłasz token w headerach a nie w cookies, mając token JWT po stronie klienta masz od razu dostęp do podstawowych informacji o użytkowniku bez konieczności odpytywania serwera itp.
Mają też dodatkowe wady :P
Jak nie trzymasz tokena w cookie tylko localStorage to tak jak wspomniał @WeiXiao tokeny podatne są na XSS. A jak trzymasz w httpOnly cookie (co niektórzy zalecają i chyba podobne zalecenia widziałem w raportach z audytu bezpieczeństwa apek) to i tak musisz się zabezpieczyć przed CSRF.
Inne wady używania JWT jako mechanizmu sesji na froncie:
- brak możliwości revokowania tokenów, wiele apek ma możliwość zakończenia sesji z jednego urządzenia na wszystkich innych urządzeniach, jeśli mamy bezstanowe JWT to tego nie zrobimy, a przy stanowym JWT musimy trzymać stan albo blacklisty po stronie serwera, czyli w pewnym sensie wracamy do starej dobrej sesji :P
- pisałeś, że mamy dostęp do podstawowych informacji o użytkowniku bez konieczności odpytywania serwera, tak to jest zaleta, ale też i wada, bo w takim razie w tokenie możemy mieć już nieaktualne dane, w zwykłych apkach webowych ja bym się raczej spodziewał, że jak przypiszę użytkownikowi rolę/zablokuję go to zmiana będzie obowiązywać od razu, a nie po np. 1 godzinie, albo przelogowaniu
- implementacja "po swojemu" jest dużo trudniejsza (nie mówię o integracjach z Auth0, Azure AD B2C, czy Amazon Cognito), a większość tutoriali pokazuje jakieś bieda implementacje, które nie mają żadnych zalet nad zwykłą i prostą sesją
Na froncie chcemy mieć sesję użytkownika, to użyjmy do tego celu sesji, a nie jakiejś protezy z JWT.
JWT jest dobre do komunikacji pomiędzy serwerami.
Albo jak chcemy wystawić nasze API do użytku innych użytkowników, ale wtedy potrzebujemy pełnej implementacji OAuth2/OIDC, a nie tego czegoś co pokazują tutoriale, gdzie wystawiają RESTowy endpoint authenticate przyjmujący login i hasło w body i zwracający token. A takie publicznie wystawione API i tak będzie się różniło od API używanego przez front (SPA), więc na zwykłym froncie ja i tak bym używał sesji.
Warto sprostować coś, co poruszył @Botek w komentarzu, bo ja też wcześniej pisałem o uwierzytelnianiu przez "cookie", a chodziło mi o sesję (gdzie zazwyczaj używa się cookie do przenoszenia informacji o identyfikatorze sesji). Porównanie bardziej dotyczy sesje vs JWT.
Jemu chyba chodziło o to, że jako zaletę przy JWT podałeś ochronę przed CSRF, co nie jest zaletą JWT samą w sobie. Jak będę przesyłał identyfikator sesji w nagłówku, to też będę zabezpieczony przed CSRF.
