L'approccio abituale è che il servizio di autenticazione emetta un token firmato dall'utente. Altri servizi possono verificare la firma per verificare che il token sia autentico. Il token contiene quindi l'ID utente. Non eseguire il rollover, ma usa invece un approccio esistente come JWT. Siate consapevoli degli svantaggi: i token non possono essere revocati singolarmente. Un token è valido fino alla scadenza o fino alla revoca della chiave di firma per tutti i token.
In molti casi tale architettura a conoscenza zero non è necessaria (beh, gli altri servizi devono almeno conoscere la chiave pubblica per la firma del token). I tuoi servizi possono parlare tra loro. Non c'è una ragione generale per cui il foo-service non dovrebbe essere in grado di chiedere al servizio utente "questo token è valido e quale utente rappresenta?".
Si noti che i servizi interni non devono corrispondere 1: 1 con endpoint visibili esternamente. Per esempio. non sarebbe inusuale fornire l'API attraverso un server che traduce semplicemente le richieste verso vari servizi interni. Questo frontend o facciata è anche un ottimo posto per aggiungere preoccupazioni condivise come l'autenticazione. I servizi interni saranno quindi protetti dal pubblico e potrebbero presumere che qualsiasi ID utente fornito sia già stato autenticato.