Cześć, ostatnio trochę zacząłem rozmyślać jakie podejście powinno być idealne w tym wszystkim.

  1. przypadku komunikacji wewnętrznej, czyli gdy już nasz end user strzelił w GW, GW w serwis, ale teraz serwis bije w kolejny serwis. Tutaj powinniśmy po prostu przekazywać dalej access_token usera? Czy każdy serwis powinien być clientem i posiadać własne tokeny i do komunikacji między serwisami przekazywać właśnie ten token? Czy może oba? Jak to powinno być rozwiązane?
  2. zakładając też komunikację z zewnątrz, ale przez inne systemy. Tutaj powinni wysyłać nam jakiś client_id + client_secret aby też GW odbijało się do Authorization Servera (tutaj też musimy mieć zarejestrowanego klienta jako ten zewn. system) z jakimś grant_type = client_credentials, tak?
  3. użytkownik po rejestracji powinien być mieć swoje entry w Authorization Serverze, ale powinniśmy też gdzieś przechowywać jego credentiale, czy tutaj potrzebny nam oddzielny context, który będzie stricte przechowywał nasze użytkownicze credentiale, tak by użytkownik miał możliwość potencjalnych działań na nim (zmiana hasła, nazwy użytkownika czy cokolwiek). Bo to nie jest już odpowiedzialność naszego Authorization Servera. Jeśli tak to posiadając takie dane w dwóch miejscach (Authorization Server i kontekst odpowiadający za chociażby zmianę credentiali, jak powinniśmy takie zmiany dokonywać?).
  4. Jak powinien odpowiednio wyglądać flow po zalogowaniu użytkownika poprzez username + password aby mógł wykonywać ciągle czynności? Czy powinniśmy bezpośrednio uzyskiwać access_token przez username + password, a następnie w jakiejś sesji trzymać ten access_token i refresh_token?

Zapewne te pytania są dość głupie i trywialne, ale im w głąb tym się bardziej zgubiłem.