Questions around the generation of user interaction redirect URLs

[aomader]

Which version of Duende IdentityServer are you using?

7.0.8

Which version of .NET are you using?

.NET8

Assumptions/Preconditions

1. IdentityServer is running under some BasePath like /bp
2. The user-interaction pages are not under that BasePath /bp, but still in the same Origin

Question 1

As I see it, the only way to redirect to a user-interaction page in the same origin but not under the same base path is to either

1. specify an absolute URL in IdentityServerOptions.UserInteraction.*
2. or write a custom IAuthorizeInteractionResponseGenerator that yields an InteractionResponse with a RedirectUrl that is also absolute.

However, in both cases there is a side-effect that the ReturnUrl will be made absolute as well (AuthorizeInteractionPageHttpWriter), although there is in this case no need to.

Is my understanding here correct?

Question 2

Assuming my understand from Q1 is correct, what is the recommendation here? This API feels like it does not fit this use-case good, although I would assume this to be a not-so-rare one.

Question 3

To the best of my knowledge, there appears to be now mechanism to alter the ReturnUrl query parameter in the interaction redirect except for renaming it.

What if I am interested in crafting URL's without that parameter or different ones? How would one approach that?

I can obviously create workarounds, but they are all hackish and brittle. I would much rather prefer a dedicated API to achieve that.

Additional Context

Asking as an Enterprise License user.

[RolandGuijt]

We do not generally recommend to host the IdentityServer beneath a path. The security model for cookie isolation works better if IdentityServer is hosted on a separate host.

The security model for cookies relies on the host being the security boundary. A cookie with a path will only be sent with requests related to that path, but it is still possible for any page/endpoint on the same host to set and overwrite cookies on that path. The same is not true for different hosts. Only the specific host can set a cookie that applies to that host.

Is there a particular reason why you would need this?
Also can you please let us know why you need the scenario as outlined in question 1?

[aomader]

I am working with a legacy configuration where currently no easy upgrade path exists. That configuration runs the IdentityServer under a specific path. Nevertheless, I am fully aware and fully agree that this is not a security best practice. However, that is the state we currently have to deal with.

Concerning your second paragraph, that is not fully correct, since sub-domains can override the parent domain's cookie for example. Not relevant for the issue at hand, just wanted to point this out.

As I said, it's a legacy configuration where IdentityServer is running under a different BasePath than the UI, but both still on the same origin.

[AndersAbel]

The way BasePath works is non-intuitive. Would you mind sharing the setup you've tried? Did you use UseBasePath()?

[maartenba]

(note: we're moving this issue to our new community discussions)

[RolandGuijt]

It seems I misunderstood the question somewhat earlier. I'm investigating this atm together with @AndersAbel