Getting 302 to the wrong location after authorization

[wasson5e]

mod_auth_openidc version 2.4.10
Apache 2.4.51

Authorization is working properly. I'm able to forward users over to the single sign on provider, and receive authorization back. When coming back to /auth (the redirect uri) I'm seeing a 302 forwarding the user back to the vanity url that I'm using, but its adding the port that the service is running on. Is there a way to remove that port being added to the redirect?

There is a reverse proxy that is forwarding the vanity url to https://localhost:4443.

OIDCRedirectURI https://<vanity>/auth
Where its going: https://<vanity>:4443

Here is what I'm seeing in the logs:
[auth_openidc:debug] [pid 16546:tid 140094686082816] src/mod_auth_openidc.c(694): oidc_restore_proto_state: restored state: {"ou":"https://<vanity>:4443/","om":"get","i":"https://<sso_provider>:8443/nidp/oauth/nam","rt":"code id_token token","n":"Vtf5IbH9E29smrxdW6SmfRQlVasGYOEtZ7JL_mI_lPQ","t":1639152445,"s":"vr0Ubcd5URogc2_tvqqm3FCKCWA"}, referer: https://<vanity>/auth
[auth_openidc:debug] [pid 16546:tid 140094686082816] src/mod_auth_openidc.c(2039): oidc_handle_authorization_response: session created and stored, returning to original URL: https://<vanity>:4443/, original method: get, referer: https://<vanity>/auth
[auth_openidc:debug] [pid 16546:tid 140094686082816] src/util.c(2566): oidc_util_hdr_table_set: Location: https://<vanity>:4443/, referer: https://<vanity>/auth

[zandbelt]

you'll need to set X-Forwarded-Port on the reverse proxy, see: https://github.com/zmartzone/mod_auth_openidc/wiki#8-how-do-i-run-mod_auth_openidc-behind-a-reverse-proxy

[wasson5e]

I have to be missing something somewhere. I hope that its something dumb. Here is the configuration in the proxy:

<VirtualHost *:443>
    SSLProxyEngine On
    SSLProxyVerify none
    SSLProxyCheckPeerCN off
    SSLProxyCheckPeerName off
    SSLProxyCheckPeerExpire off
    ServerName <vanityurl_log>
    ServerAlias <vanityurl_short>

    ProxyPass "/" "https://localhost:4443/"
    ProxyPassReverse "/" "https://localhost:4443/"

    RequestHeader set X-Forwarded-Host "<vanityurl_long>"
    RequestHeader set X-Forwarded-Port "443"
    RequestHeader set X-Forwarded-Proto "https"
</VirtualHost>

And here is what Im seeing in the redirect:

Connection: Keep-Alive
Content-Length: 228
Content-Type: text/html; charset=iso-8859-1
Date: Thu, 16 Dec 2021 16:19:32 GMT
Keep-Alive: timeout=5, max=100
Location: https://<vanityurl_long>:4443/
Server: Apache/2.4.51 (Unix) OpenSSL/1.0.2k-fips
Set-Cookie: mod_auth_openidc_state__S-QLuFXo2sd5op371gtvuR5kMA=; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT; Secure; HttpOnly; SameSite=None
Set-Cookie: mod_auth_openidc_session=f48b8b76-5e8b-11ec-be65-afa1b7eb0e54; Path=/; Secure; HttpOnly; SameSite=None

Here is the loglevel debug on the authentication location:
[Thu Dec 16 16:19:33.790425 2021] [auth_openidc:debug] [pid 129357:tid 140094358898432] src/mod_auth_openidc.c(2039): [client 10.151.115.216:61461] oidc_handle_authorization_response: session created and stored, returning to original URL: https://<vanityurl_long>:4443/, original method: get, referer: https://<vanityurl_long>/auth [Thu Dec 16 16:19:33.790432 2021] [auth_openidc:debug] [pid 129357:tid 140094358898432] src/util.c(2566): [client 10.151.115.216:61461] oidc_util_hdr_table_set: Location: https://<vanityurl_long>:4443/, referer: https://<vanityurl_long>/auth [Thu Dec 16 16:19:32.336074 2021] [auth_openidc:debug] [pid 129357:tid 140094358898432] src/mod_auth_openidc.c(694): [client 10.151.115.216:61461] oidc_restore_proto_state: restored state: {"ou":"https://<vanityurl_long>:4443/","om":"get","i":"https://login.esso-uat.charter.com:8443/nidp/oauth/nam","rt":"code id_token token","n":"K3MwTOa79GjKUvzP0Aooh5WLkt1R_kUuT9wbiO4ephk","t":1639671559,"s":"_S-QLuFXo2sd5op371gtvuR5kMA"}, referer: https://<vanityurl_long>/auth

[zandbelt]

looks like the RequestHeader doesn't work indeed, the full logs would show you which headers are being sent and interpreted; perhaps also use the "early" flag on the RequestHeader directive

[wasson5e]

Turns out that there was a iptables rule that was redirecting traffic and causing issues.