[SendMeAnAngel]

Jaki jest powód, że w OAuth wycofano typ PASSWORD? Mam aplikację SPA, gdzie jest przycisk "Zaloguj", pokazuje się okno modalne, użytkownik podaje login/hasło, serwer zwraca token JWT i ten token przechowujemy po stronie przeglądarki (póki co w localStorage, docelowo w ciastkach). To działało w starym Springu z spring-security-oauth2-autoconfigure i konfiguracja była prosta. Obecnie istnieje https://docs.spring.io/spring-authorization-server/reference/overview.html ale typ PASSWORD jest nieobsługiwany. Taką architekturę wymusił klient, że aplikacja składa się z serwera uwierzytelniania oraz monolitu z pozostałymi REST API, ale w sumie to po co? Nic nie stoi na przeszkodzie, aby aplikacja SPA była stateful, czyli w ciastkach trzymamy ID sesji, a serwer wie, kto jest uwierzytelniony? Obecnie jest tak, że to serwer proxy parsuje JWT i przekazuje dalej ID użytkownika, a cała apka jest stateless. Pewna przeszkoda to możliwość istnienia wielu instancji aplikacji, ale dane o sesjach można sobie gdzieś przekazywać między node'ami (np. kolekcje Hazelcast). Jak to jest u was zrobione? #programowanie #backend #java #spring

[Waffenek]

@SendMeAnAngel znpassword grantem jest wiele problemów. Nawet pomijając fakt że wymaga mocnego powiązania klienta frontendowego z samym procesem logowania, co utrudnia implementacje wszelakich 2FA to jeszcze uniemożliwia single sign on z zewnętrznych providerów jak google, facebook lub firmowe SSO.

Jednak największym problemem jest to że udostępnia samej aplikacji hasło wpisywane przez usera. Jako backend nie masz żadnej gwarancji że ktoś robiący aplikacje mobilną nie zdecyduje się ułatwić sobie życia i zapisanie