Thanks for the quick reply @Scott. I’m not sure how I can get what I’d like. I edited the post with numbers on each step and added the original request that gets proxied.
The key is that in step 1, all query parameters get proxied. In 4, only query parameters included in the Location header are proxied. I believe what you are suggesting is for me to create a rule above my /api/* rule. Something like the below.
/api/oauthCallback code=:code state=:state https://api.mydomain.com/api/oauthCallback?code=:code&state=:state 200!
This rule will match routes with exactly this path and query params /api/oauthCallback?code=:code&state=:state. The problem with this approach is that my oauthCallback takes lots of different parameters. I see the docs you linked suggesting to enumerate all the possibilities. That number could be quite large in this case (the route takes a whole different set of optional parameters under error conditions). On top of that, all it takes is the auth service to start calling our /api/oauthCallback with one additional parameter to break our login flow. Does this sound correct or am I missing something?