Allow full HttpResponse control from IAuthorizeInteractionResponseGenerator

[aomader]

Currently, the IAuthorizeInteractionResponseGenerator allows for customizing the user interaction flow by returning an InteractionResponse object. This object signals to IdentityServer whether to show a login, consent, or error page, or to perform a redirect in an abstract fashion.

However, for more advanced scenarios, this model can be limiting. It would be highly beneficial to have a mechanism to completely take over the response generation from within a custom IAuthorizeInteractionResponseGenerator implementation.

This feature would involve:

1. Providing the IAuthorizeInteractionResponseGenerator with the context of the HttpResponse that will be sent to the client.
2. Passing the returnUrl (which is generated later in the pipeline) to the generator, so it can be used in the custom response.
3. Allowing the generator to "short-circuit" the default response handling and write directly to the HttpResponse object, giving developers full control over the status code, headers, and body.

This would enable more complex and customized user interaction flows that are not easily achievable with the current InteractionResponse properties.

We are dearly in need of such a feature to optimize our response generation without resorting to really dirty workarounds.

[wcabus]

Would you be able to share a bit more on your specific use-case why you would need this level of control?

Perhaps there is another way to achieve what you need without resorting to a dirty workaround as you described. Additionally, this level of change would most likely be a breaking one. Since we already released a v8 alpha version for Duende IdentityServer, I am not sure that this change would still make it into the v8 final release.

[aomader]

Of course, let me share some more details.

When we are evaluating the needed response and see that it requires interaction instead of going directly back to the client, we always establish a custom process-specific session on the server side. That means we do not need nor want the returnUrl to be part of the URL we redirect to, but instead a cookie plus a custom session identifier in the URL. We still need the returnUrl to craft the redirect correctly though, obviously. Additionally, our identity server is registered with a base path that is always prepended to local redirect URLs, but the pages we are redirecting to do not live under this base path, hence the URLs would be incorrect.

So in short,

• we need the HttpResponse to set cookies and redirect URL with status code
• we do not want the returnUrl to be appended always
• the base path should not to be always prepended (we also do not want to set an absolute path)

I hope this helps.