no worries let me try being more concrete:
Let’s say we have a BFF (backend for frontend) that a user connects to with his browser and is sent into an OAuth2 authorization code flow redirect dance to Okta. This BFF has some client id that is passed as part of the redirect to Okta. The user happily authenticates and gives some consent for access rights for a downstream service which is living behind an API Gateway. The BFF will have to issue its call through this gateway in reaching the downstream service. Okta issues an authorization code, which the BFF will receive.
All fine, if the service was not living behind a gateway, the BFF would now on a backend channel with the very same OAuth2 client id go to Okta and exchange the authorization_code for an access-token. But in our case it will not do that, but rather pass the authorization_code on to the gateway, which will only then (protecting its security domain), go with its own OAuth2 credentials go to Okta for the exchange.
Will that work ? or does the OAuth client id have to match with the original id used in the frontend flow that produced the authentication_code ?
hope its clearer now