Zabezpieczenie połączenia API to API

Mam od pewnego czasu przemyślenia odnośnie zabezpieczenia połączenia API to API.
Założenia są takie, że obydwie aplikacje są hostowane w chmurze, u mnie jest to Azure, i w tym kontekście będę się trzymał, ale podejście w każdej będzie podobne.

Jakie znam sposoby zabezpieczenia:

• client id & secret: dość popularne połączenie, ale tego jeszcze nie implementowałem, ale widziałbym tutaj wykorzystanie KeyVault gdzie trzymamy clientSecret, natomiast gdzieś w bazie trzymamy nazwę klucza, którą wyciągniemy za pomocą clientId i sprawdzimy wartości

• token JWT generowany w kontekście aplikacji: to ostatni raz implementowałem kilka lat temu (jeszcze z wykorzystaniem IdentityServer), do poprawnego działania należy dodać access w APP registration w danym API

• token JWT od usera: z tym się też bardzo często spotykam, wykorzystujemy token z bierzącego bieŻącego requestu, do komunikacji z innym API, tutaj też jest wymagana odpowiednia konfiguracja w app registration

• one-time token: jest to metoda bazująca na nieodwracalnym szyfrowaniu, tak aby nie dało się podejrzeć co jest źródłem, taki token można wykorzystać przez określąną ilość razy, zazwyczaj jest to 1, w skrócie jak to działa, na podstawie modelu jaki wysyłamy tworzymy taki token z wykorzystaniem szyfrowania Base, do takiego modelu dodaje się jeszcze jakiś time-stamp, no i oczywiście zanim wrzucimy do Base można to jeszcze jakoś zaszyfrować z użyciem salt, tak nawet przy wyłapaniu takiego requestu i po zmianie modelu autoryzacja się nie uda, no i tutaj wymagane jest aby API miało ten sam algorytm do generowania takiego tokenu

Ja chciałem iść w najprostsze rozwiązanie - client id & secret. Usłyszałem, że to można podsłuchać i lepiej wykorzystać token generowany w kontekście API
no ale taki token też można podsłuchać, jedynie ma krótszą żywotność od client id & secret
Pomijając problem podsłuchu w usługach chmurowych

Jak Wy zabezpieczacie takie połączenia?

Nie wystarczy założyć tunel SSH / Wireguard / OpenVPN między maszynami / vmkami / kontenerami i API wystawić tylko po tym tunelu?

Wtedy obejdzie się bez żadnych ekstra szyfrów, bajerów i cudów; proste w zainstalowaniu (no, może poza wariantem OpenVPN), proste w zarządzaniu, proste w debuggowaniu i do tego w zasadzie w 100% bezpieczne (wliczając nawet rzeczy w stylu replay attack).

Najczęściej implementowałem to za pomocą opcji 1 i 2. Obecnie praktycznie zawsze korzystam z OAuth Client Credentials Flow, który jest dedykowany do połączeń serwer-serwer (bez wykorzystania tożsamości użytkownika) w przeciwieństwie do Auth Code Grant czy on-behalf flow.

Tak, OAuth znam oczywiście, ale
Jak masz w jednym tenant n applikacji
To jesteś w stanie w aplikacji x wygenerować token i zautoryzować się nim w aplikacji y, gdzie aplikacja y nie wyraziła na to zgody
nie jest to duży problem jak tych aplikacji jest kilka, większy się robi jak mówimy o kilku setkach aplikacji

@Szaraczek: Ogólnie nazywa się to M2M(Machine-to-Machine flow) w kontekście oauth. Dodatkowo jeśli chodzi o podebranie tokenu no to jeszcze możesz rozważyć mTLS.

Poza tym JWT sam w sobie nie służy do mówienia co kto może z czym zrobić. Jest to nośnik informacji o kliencie z podpisem który gwarantuje, że te informacje nie zostały zmienione.
To w jaki sposób opendzlujesz sobie to jest twoją sprawą. Możesz w JWT traktować jako nośnik autentykacji tj serwis X jest serwisem X i to gwarantuje ci własnie token. A możesz w tokenie np dodać role w clamiach i traktować to w sposób autoryzacyjny.

#Edit
Tak jeszcze wspomnę jak chcesz mieć juz wgl kontrole kto do czego woła to obczaj temat "service mesh". Ja używam głównie tego w aktualnym projekcie. Wtedy wszystkie requesty idą przez proxy który sprawuje kontrole nad tym co kto może wołać. A same serwisy nie mają bezpośredniego kontaktu ze sobą.