Invoking /authorize PKCE endpoint from server

[kelvin.lo]

I have a client app that sends some parameters to the /authorize endpoint that I would need to capture/validate before passing the request to Auth0’s /authorize endpoint. After I captured request in my mediation tier, validated the data, then invoked Auth0’s /authorize from my backend servers (using the /authorize PKCE flow), I get a 200 OK response rather than a 302 (Found). But when I hit the same endpoint using RESTlet in my browser, I get the expected 302 (Found) response.

How can I call the /authorize PKCE endpoint from my server such that it’ll return the proper 302 response? I understand this is unconventional, but I need this capability because Auth0 currently does not support the signed request object parameter. (Final: OpenID Connect Core 1.0 incorporating errata set 1)

[jmangelo]

The /authorize endpoint is not meant to be called from the back-end, however, the back-end can issue a redirect response to the /authorize URL. Something like:

1. The browser/end-user navigates to https://app.example.com/login?x-param=something;
2. The application back-end processing the above request redirects to /authorize?auth_params... after capturing/validating the data.
3. The request is received by Auth0 service that depending on a few things can either immediately redirect back to the client application or display interactive page (for example, for the end-user to complete authentication).

From your description it seems that the back-end is calling the /authorize endpoint as it would call another HTTP service to obtain some data and then provide a response back, but /authorize is not meant for such a flow.

[kelvin.lo]

Thanks for the response. It turns out the library (resttemplate) that I used to call the backend was following the 302 redirects from the /authorize call, so I wasn’t seeing the 302. Turning off the redirect following allowed me to capture the response from /authorize. Also, I’ve noticed that the /authorize endpoint turns away requests that doesn’t have a valid user-agent header, but that was solved by forwarding the caller’s user-agent. All in all, I got it working the way I need it to work. Thanks.