Your first option has an additional threat vector - the UA token is repayable against the first service. In case of compromise, as you say, the toke is too powe

Your first option has an additional threat vector - the UA token is repayable against the first service. In case of compromise, as you say, the toke is too powerful and can do too much. The second option is indeed bad. The third option is used heavily in production for both cost savings and latency reduction. There's a 4th option which is to go back to your auth server with the UA token and get a new one representing all the data you discuss in your tuple, but still signed and valid representing (a, user, b). This is the on behalf of flow, and is standardized in oauth2 under the name Token Exchange, roughly. (E - actually, my 4th and your 3rd are the same. My 3rd is an improvement to not require minting a new token)