Jak mikroserwisy ufają sobie nawzajem

Ostatnio zainteresowałem się tematem security i próbuję zrozumieć temat oauth 2.

Jeśli coś pomieszałem to proszę mnie poprawić.

(Aplikacja kliencka - moja aplikacja którą piszę.)
Jeśli użytkownik próbuje uzyskać dostęp do jakiegoś zasobu np. test.pl/zasob1 to:

1. zostanie przekierowany do serwera autoryzującego w celu zalogowania się np. logując się swoim kontem gmail.
2. Serwer autoryzujący w odpowiedzi przekaże autorization code aplikacji klienckiej.
3. Aplikacja kliencka wyśle Autorization code do serwera zasobów (resource server i autorization serwer może być tym samym bytem?) i wymieni go na token.
4. Za każdym razem jak uwierzytelniony już użytkownik będzie próbował dostać się do zasobu w requescie zostanie przesłany również token.
5. Aplikacja kliencka za każdym razem wyśle żądanie do serwera wydającego token np. google sprawdzając czy token jest poprawny oraz ważny.
6. Jeśli wszystko jest okey to użytkownik otrzyma dostęp do zasobu.

Można wykorzystać JWT (JSON Web token) w aplikacji i dzięki temu aplikacja sama sprawdzi czy token jest poprawny i dalej ważny. Nie musi odpytywać za każdym requestem do swoich zasobów o to serwera autoryzacyjnego.

Moje pytanie brzmi.

1. Czy dobrze rozpisałem powyższy flow.
2. Po co dostawać autorization code i wymieniać go na token? Co to daje i czemu od razu nie dostaje się tokena?
3. Co w przypadku komunikacji wewnętrznej pomiędzy mikro serwisami? Pomijają punkt z uwierzytelnianiem (kim jesteś?) i tylko wystawiają sobie na wzajem token?

1. Nie do konca, krok #5 jest bardzo często pomijalny, bo jest on bardzo kosztowny czasowo, a nie zawsze jest sens go wykonywac, dodatkowo usługi oAuthowe maja jakies rate limits. Token wydaje sie na X czasu, jesteś w tanie zcachować go w swoim systemie, do tego masz tez coś co nazywa się Scopes w oauth2.

Z reguły token odnawia się jeśli użytkownik sam o to poprosi(za pomocą jakiegoś mechanizmu):

• endpoint logowania
• nagłówek zmiana scope, itp...

2. Nie wymieniasz kodu na token, tylko login, haslo, ewentualnie drugi skladnik ktory jest kodem na TOKEN. A dlaczego to robisz? Bo token jest generowany na jakiś czas i z reguły systemy mają mechanizmy, które pozwalają anulować wydane tokeny.

Tokeny tez mają uprawnienia, mając usera z uprawnieniami admina, można poprosić o token, który ma dostęp na poziomie normalnego użytkownika, albo po prostu do pobierania jakichs danych z API, bez ich zapisywania... Jeśli wycieknie token, to jest on z reguły limitowany, i wygaśnie za 20-30 min...

3. Wewnątrz komunikacji nie potrzebujesz tego tokenu do komunikacji. Potrzebujesz go tylko do tego, aby sprawdzić czy użytkownik ma dostęp do zasobu, z reguły jest odpowiedzialny za to system...

Do komunikacji pomiędzy serwisami powinieneś wykorzystać mechanizm szyfrowania, np TLS, czy coś innego...

Diagramy przepływu OAuth różnią się w zależności od tego co z czym i przy użyciu czego się łączy :)

Ogólna abstrakcja, polega na tym, że możesz rozdzielić uwierzytelnianie, autoryzację i usługę, czyli:

Klient wykonuje jakiś tam ciąg operacji i uzyskuje token potwierdzający tożsamość, rolę.
Przy jego użyciu wykonuje żądanie do innego serwisu i otrzymuje autoryzację na skorzystanie z konkretnej usługi w postaci tokenu OAuth
Wykonuje żądanie do zabezpieczonej usługi, jeżeli token OAuth jest poprawny, usługa zwraca dane.

Wszystkie tokeny mają jawnie określony czas życia, więc klient wie, czy token jest jeszcze ważny, czy już trzeba go jakoś odświeżyć.
Token nie wymaga synchronicznego potwierdzenia u wystawcy.

W przypadku usług z UI flow jest uzupełniony o przekierowania, czyli próbujesz się dostać do jakiejś strony (secured.com) bez ważnego tokenu:

• strona przekierowuje cię do dostawcy tożsamości, wraz z informacją dokąd masz wrócić np. identify.me?target'secured.com
• po poprawnym uwierzytelnieniu zostajesz przekierowany z powrotem na stronę secured.com (z target), ale już z odpowiednim tokenem

Warto zerknąć np. tutaj:
https://docs.microsoft.com/pl-pl/azure/active-directory/develop/v2-oauth2-auth-code-flow

Po co dostawać autorization code i wymieniać go na token? Co to daje i czemu od razu nie dostaje się tokena?

Ze względów bezpieczeństwa. Trochę by było słabo jakby do użytkownika do urla w przeglądarce wrócił access_token,
nie wspominając, że mógłby taki token gdzieś po drodze wyciec to użytkownik nie powinien go znać i np. złośliwie coś nim robić w imieniu
serwera, który chce go uzyskać. Dlatego wraca authorization_code, który później jest wymieniany przez backend na access_token.
Backend musi podać parę client_id i client_secret więc tylko backend na podstawie authorization_code może taki token uzyskać.