Projekt api - proszę o sugestie

Narysowałem sobie projekt api jakie chce przygotować

Chcę was prosić o pomoc z poprawnym zaprojektowaniem takiego systemu.
Klientów korzystających z API tez muszę napisać, ale to inny temat. Na razie wiadomo tylko tyle ze będzie aplikacja desktopowa i aplikacja mobilna, może kiedyś tez strona www. Od strony API planuje zrobić api uwierzytelniające/autoryzujace które będzie miało swoją bazę użytkowników. W bazie tej będą loginy, hashe haseł i uprawnienia do roznych dostepnych dla uzytkownika aplikacji. Zarzadzanie tąbazą będzie również przez Authentication Api, administrator całego systemu będzie zarządzał uzytkownikami i ich uprawnieniami.

Powstanie rowniez kilka API aplikacyjnych (4 lub 5) . Wszystkie Api aplikacyjne beda podpiete pod baze aplikacyjna (niektóre bedą miały tam swoje tabele, inne beda roweniz korzystały ze wspólnych tabel)

Teraz wracając do projektu przedstawionego na rysunku. Widzę to tak:

• użytkownik John Doe aby się uwierzytelnić wysyła login i hasło do Authentication API (1)

• Authentication Api kontaktuje się z baza uzytkownikow i sprawdza dane dla loginu john-doe

• Jeśli podane przez klienta dane sa poprawne to zwracany jest JWTToken w którym zawarta będzie uzytkownika john-doe (2)

• klient potrzebuje wyciagnac faktury dla wybranego kontrahenta o id=123. W tym celu wysyła do api** Application 1 API **odpowiedzialnego za aplikacje fakturowania requesta na adres api/faktury?kontrahent=123 (3). W request przesyłany jest tez JWT

• Application 1 Api po otrzymaniu tego requesta odczytuje z JWT nazwe uzytkownika i odpytuje Authentication Api czy uzytkownik o nazwie john-doe ma uprawnienia pozwalajace pobrac faktury tego kontrahenta (4).

• Authentication API sprawdza w bazie czy uzytkownik john-doe posiada upranienia do akcji pobierania faktur (tutaj też chciałbym jakoś sprawdzić czy uzytkownik moze pobrać wszystkie faktury czy np ma uprawnienia tylko do pobrania okreąlonej ilości faktur)

• zwracana jest informacja czy uzytkownik john-doe ma prawa do tej akcji kontrolera oraz np ile faktur moze pobrac, ewentualnie jeszcze jakies inne informacje na temat przyslugujących uprawnien(5)

• Application 1 API na podstawie uprawnien pobiera dane z App Db i zwraca je użytkownikowi lub zwraca informacje o braku uprawnien (6)

Pozostałe aplikacje mają działać na podobnych zasadach.

Proszę o jakieś uwagi, wskazówki.Możliwe ze jakiś senior zrobiłby taki system w tydzień ale ja jestem poczatkujacy i błądzę po omacku :) Gdzieś czytałem ze tego typu problemach uzywa sie mikroserwisów, ale mam chyba jeszcze za małą wiedze zeby pójść w tym kierunku.

1. Re Dlaczego tak sobie to utrudniasz? Jaki jest powód takiego podziału? - AdamWox dziś, 17:38

jestem tego samego zdania

A dlaczego nie
Client <-> Application n <-> A&A module
Nie wszystko musi być webserwisowo. W małej firmie to bardziej przeszkadza niż pomaga
Sposobów "przelotu" informacji A&A "przez" aplikację są dziesiatki

2. Zwykle szybko przychodzą czasy, że potrzebna jest granulacja autoryzacji do wybranych czynności w apliakcjach.
   I niezależność (ortogonalności) tych serwisów idzie się ...

3. Subiektywnie to odczuwam, jakby idea wyszła od "frontowca".

Brawo, odkryłeś właśnie single sign-on. Tutaj masz listę gotowych implementacji https://en.wikipedia.org/wiki/List_of_single_sign-on_implementations
Zainstaluj sobie, użyj gotowego api (które w większości działają na podobnej zasadzie jak na narysowanym przez Ciebie schemacie) i nie ma potrzeby wynajdowania koła na nowo

@AnyKtokolwiek czyli lepszym rozwiązaniem może być trzymanie uwierzytelniania i autoryzacji bezpośrednio w api aplikacji niż w osobnym serwisie? Problematyczne może byc wtedy jesli kilka aplikacji mam miec tych samych uzytkowników. Trzeba będzie w kazej bazie zakładać tych samych userów.

kalimata napisał(a):

@AnyKtokolwiek czyli lepszym rozwiązaniem może być trzymanie uwierzytelniania i autoryzacji bezpośrednio w api aplikacji niż w osobnym serwisie? Problematyczne może byc wtedy jesli kilka aplikacji mam miec tych samych uzytkowników. Trzeba będzie w kazej bazie zakładać tych samych userów.

Skąd ten wniosek?
Dlaczego zakładasz, że baza/struktura danych musi być 1:1?

Znakowo nie mogłem narysować więcej, ze skośnymi kreskami

Nie podoba mi się komunikacja pomiędzy application api a authentication api, jeśli do każdego requesta do application api będziesz strzelał synchronicznie do authentication api to to będzie wolne i podatne na błędy. Ograniczyłbym tą komunikację do minimum, zostawiłbym oddzielne api do uwierzytelniania, natomiast autoryzację bym przesunął do api aplikacyjnych.