Multiple OIDCRedirectURIs for single vhost?

[shreck8754]

For applications hosted across multiple domains or entry points (HTTP/HTTPS), is it possible to configure more than one OIDCRedirectURI in a single vhost? We can assign multiple redirect URIs to a single client within our OpenID provider (as is the case with most providers), so it painful having to create separate vhosts in Apache to handle this scenario.

Example situation...

URI 1 - https://myfirstapp.internaldomain.com
URI 2 - https://myfirstapp.externaldomain.com

Would be nice to do something like this...

OIDCRedirectURI ['https://myfirstapp.internaldomain.com/redirect_uri', 'https://myfirstapp.externaldomain.com/redirect_uri']

...rather than creating separate vhosts and OIDC configuration files.

[zandbelt]

That's a possible enhancement but it would also require a way to indicate which redirect URI you'd want to use when creating the authorization request, probably using hostname matching. It is not without its own complexity and can be seen as only an optimization for vhosting rather than adding a lot of value for mod_auth_openidc itself. I'll leave this as an open enhancement ticket.

[mguillem]

What about using some variable substitution or to allow to specify a path that gets evaluated relative to currently requested URI? This would allow to test a configuration on a different environment without to change the OIDCRedirectURI.

[zandbelt]

That seems reasonable but my reluctance is also based on the fact that the vast majority of attacks against OAuth/OpenID Connect is about manipulation, trickery and "sloppy matching" of the Redirect URI. By having a hard-configured single value that must match the hard-coded single value configured on the OP side there will never be any confusion or oversights in the effect of configuring a bunch of Redirect URIs on different vhosts that may be managed by different persons/parties (and forget about some after a while).

I would consider a PR that makes this optionally enabled behaviour. I don't expect to work on it myself on the short term.

[mguillem]

Perhaps a silly question as I'm still new using OIDC: couldn't OIDCRedirectURI have as default something like following

protocol, host and port from original request + "/oidc_redirect_uri/" + some random number if it has to be hard to guess

This would allow to make OIDCRedirectURI optional, making configuration even easier.

[zandbelt]

The OIDCRedirectURI needs to be registered with the Providers, so the value needs to be known in advance and fixed.

[glatzert]

Hey everyone, the RedirectUri Needs to be known in advance - that is correct, but it needs not to be fixed. The ASP.NET-Core Implementation of OIDC uses Request.Schema + Request.Host + Configurable-Path, which essentially ends up with https://myapplication.domain.tld/signin-oidc. (I'm not sure about the port, but I think it's omitted).

Especially for CMS Multisite Systems this would be very practical to have in this module as well. In the IDP the RedirectURIs still have to be registered.

Perhaps setting a relative path as RedirectURI would be an Option? I could possibly find someone here to provide a PR allowing relative paths in Redirect URI.

[zandbelt]

Yes, I do agree that would be a good implementation of this enhancement.

[glatzert]

So I'll find someone @moschlar in my team to send an PR to you :)

[zandbelt]

Sound good; if you want to expedite otherwise you can contact me at hans.zandbelt@zmartzone.eu

[moschlar]

See https://github.com/pingidentity/mod_auth_openidc/pull/258 😀

[osamaramihafez]

Thanks @moschlar! it would be nice to see an example usage of this solution with multiple uris if you could share :)

[moschlar]

@osamaramihafez We didn't actually implement support for multiple uris (like in the initial post in this issue) but instead support for relative uris.

So for example when you have

OIDCRedirectURI /redirect_uri
....
<VirtualHost *:443>
    ServerName myfirstapp.internaldomain.com
    ...
</VirtualHost>
<VirtualHost *:443>
    ServerName myfirstapp.externaldomain.com
    ...
</VirtualHost>

Apache and mod_auth_openidc will use the appropriate uri per virtual host.

(OTOH, ServerAlias should also work, though I'm actually not quite sure about the interaction with Apache UseCanonicalName - we should probably test that some time.)

Does that help?

[osamaramihafez]

@moschlar Hmm, interestingly enough, I only have one host (the main host configured in httpd.conf), but I was able to make the uri work for multiple different locations. It looks like a bug if I'm not mistaken, but it works in my favor lol.

So for example:

OIDCRedirectURI /view/path_x

<Location /view/path_x>
        AuthType openid-connect
        Require valid-user
</Location>

<Location /view/path_y>
        AuthType openid-connect
        Require valid-user
</Location>

The OIDC redirect uri seems to work for both paths, redirecting me to /view/path_x when I hit /view/path_x and redirecting me to /view/path_y when I hit /view/path_y ... but the redirect uri is clearly set to /view/path_x. Right now I'm just wondering why it also works for /view/path_y. But I'm happy that it works right now lol.

Forgive me for anything that's not clear, I'm new to apache.

[glatzert]

That’s to be expected: Quoting the readme of the module:

OIDCRedirectURI is a vanity URL that must point to a path protected by this module but must NOT point to any content

OIDCRedirectURI https://www.example.com/example/redirect_uri

You might get problems, if the path is used for any content, so you probably want to use some non-existing path as redirect target for the auth server. After the auth server returned to your app the module will redirect you to the location you came from.

[zandbelt]

The OIDC redirect uri seems to work for both paths, redirecting me to /view/path_x when I hit /view/path_x and redirecting me to /view/path_y when I hit /view/path_y ... but the redirect uri is clearly set to /view/path_x. Right now I'm just wondering why it also works for /view/path_y. But I'm happy that it works right now lol.

it seems you're confusing/conflating the redirect URI with the URL your trying to access

[ronhaines]

Apologies, new to OIDC and configuring it. Got stuck/worried about the same point as @osamaramihafez raised. Not sure what OIDCRedirectURI is used for. If OIDCRedirectURI were used to validate the url the web browser is sent back to after authentication, then it is unexpected that loading /view/path_y would work (if OIDCRedirectURL points to host/view/path_x). I assume that means OIDCRedirectURI is used for some other purpose and not used to validate the url the browser is sent back to.

[glatzert]

The redirect URL is for the protocol, as in "where does the IDP send it's response" - therefore the OIDC module needs to be in control of that URL and inspect the request, validate it and set a cookie to signal you've been logged in. After that you are redirected to the original protected request path. It's best practice to set it to something non-existing like /signin-oidc and let the module handle everything else.