Connector redirectURI restriction?

[zenarcher007]

The issue I am having is similar to this issue, in that the redirectURI of (of most connectors; assume oidc in this case), is not allowed to differ from the callback domain of the issuer URL.

Specifically, in the function "LoginURLs" of [oidc.go, for instance], I am wondering about these lines:

if c.redirectURI != callbackURL {
  return "", fmt.Errorf("expected callback URL %q did not match the URL in the config %q", callbackURL, c.redirectURI)
}

For instance, consider this (simplified) dex-config.yaml:

config.yaml: |
    issuer: http://dex.auth.svc.cluster.local:5556/dex
    # As described in the mentioned issue, setting both this and the oauth-proxy parameters
    # to the external URL, https://kubeflow.domain.org/dex, did not work.

staticClients:
    - idEnv: OIDC_CLIENT_ID
      redirectURIs:
      - "/authservice/oidc/callback"
      - "/oauth2/callback"
      name: 'Dex Login Application'
    secretEnv: OIDC_CLIENT_SECRET

### External Connectors
connectors:
    - type: oidc
      id: keycloak
      name: Keycloak
      config:
        issuer: https://my.domain.org/auth/realms/master

        clientID: "kubeflow"
        clientSecret: "_.-^-._.-^-..."

        ### This is the actual redirectURI I want to redirect to,
        ### but Dex throws an error if this is not set to "http://dex.auth.svc.cluster.local:5556/dex/callback",
        ### in which case the end-user's browser will redirect to this non-accessible URL
        redirectURI: https://kubeflow.domain.org/dex/callback

From my understanding, such a configuration would make sense both in that this a minimally-changed configuration from the (functioning) default, in that effectively, only the "connectors" section is added, and that it should inherently be more secure for Dex to communicate more within the cluster's internal network as opposed to making additional requests "externally". As I would guess that both function parameters would be passed based only on configuration values, my impression was that this explicit check mainly exists to prevent a misconfiguration, although it is possible that there could be something I am not understanding.

In my case, I researched and tried many attempts at working around this, and eventually decided to modify the source code and change this error into a warning that does not return from the function and rebuild, which solved all of my login issues. My questions are:


a) Are there specific reasons for having this check that I should understand?
b) Are there any security implications for removing the explicit requirement that the issuer and redirect URLs must be similar in the code?