If we pass to an API gateway an auth code can it then invoke the /token endpoint with its own OAuth credentials and exchange the authorization_code for an access token?
Additionally, can the token endpoint support an additional parameter, such as id_token parameter in the /token endpoint for the Client Credentials Flow
or can we exchange an existing access token (for some API) for an authorization_code (to another API)
Hey @Govner!
I’m not sure I understand your question completely. It sounds like you have an API Gateway and you have questions around passing tokens to other services (behind the gateway)?
Heya @bdemers
yes, true - that is what @Govner (and myself 
) have as a scenario and a couple of questions on those accounts.
The first question refers to a scenario where an API Gateway receives an authorization code and the gateway-embedded OAuth client is not the one that was referenced in the original “redirecting” of the user in the frontend-flow of the authorization code grant type flow.
Cheers.
Are the services behind the gateway also perform OAuth 2 Authorization code flow redirects?
Those services behind the gateway are the ones the authorization_code “targets” (of course only after being exchanged for an access token but in our scenario, by the gateway with its OAuth2 client credentials, and not by the OAuth2 client “part” of the frontend-flow). To answer your question, those services are not performing any redirects but are the targets receiving the access token stemming from the backend-flow of the OAuth2 authorization code flow, which itself is exercised by the gateway OAuth client.
Sorry guys, I’m still not sure I understand the question.
Do you have any form of auth between the gateway and the service (or is that what you are asking?)
Also, what stack are you on? We might be able to suggest an existing library.
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
I assume the token endpoint can have the code parameter specified by the API gateway assuming the API gateway also knows the client ID and secret of the original requesting application: https://developer.okta.com/docs/api/resources/oidc#request-parameters-1