Add extensibility points to the /connect/authorize/callback endpoint

[CoderNumber1]

Which version of Duende IdentityServer are you using?

6.2.4

Which version of .NET are you using?

net6.0

Describe the bug

In previous versions of IdentityServer, there existed some mechanism of customizing the html returned on /connect/authorize/callback. Admittedly, this was in 3.x of IdentityServer; but by providing a template for that page I was able to customize it so that it provided the user some indication of what was going on in cases where the application they were redirecting to was slow to respond. I've yet to find any analogue of this feature in the current version of IdentityServer. Is there was way to configure or override the contents of that page in 6.x?

To Reproduce

N/A

Expected behavior

I would hope there's a way to either register a controller/action to be called on the callback endpoint that I could provide a customized view, or otherwise some sort of callback that I could provide custom html content to be injected on the callback page. This would allow me to provide a customized message to our users that would indicate to them the purpose of the page they're on. In contrast, currently if the calling application is slow to respond on callback, the user just sees a blank white page while they wait for the application to respond.

Log output/exception with stacktrace

N/A

Additional context

I've considered using a middleware to look for and intercept the response from the callback endpoint, and then attempt to inject our desired content in the response. However, this seems like a bit of a hack, subject to breaking should IdentityServer need to change something about the callback operation/output in later versions. If this is the best means of accomplishing a custom message on the callback page, then so be it. I'm hoping though that there's an already supported solution to our requirement that I'm just not able to find in the documentation.

[brockallen]

Hi @CoderNumber1 -- In our next release we have opened up our response generation to be extensible to allow thing like your request:

#1342

[CoderNumber1]

@brockallen fantastic timing! We'll be keeping a close eye on 7.0 then!

I was looking over the changes in that PR, and I have a follow-up question. Looking at the current default IEndpointResultGenerator<AuthorizeResult> implementation it would still be an internal class as of right now. Meaning we could inject our own IEndpointResultGenerator<AuthorizeResult>, but we would need to duplicate the entirety of the behavior that the current default exhibits in order to override the subset that returns the form post response.

Are there any plans to make that a public class, and possibly make some of the currently private methods protected virtual, such as GetFormPostHtml?

[brockallen]

Well, we were going to wait until we got feedback. So that's a start. Have a deeper look and provide some ideas on how we would need to change it so you can extend what you need/want to.

[josephdecock]

@CoderNumber1 - any further thoughts on what you'd like to be able to extend in the result generators?

[CoderNumber1]

My apologies, I've been buried and this fell off my radar.

In particular all I really need is to be able to extend on the current AuthorizeResultGenerator is the GetFormPostHtml(AuthorizeResponse response) method. I don't even really need to be able to override the entirety of the response, just inject additional content for the body of the page. If that method were protected virtual instead of private I could just inherit from the existing implementation and override the one method. This would save me from having to implement the entirety of IEndpointResultGenerator<AuthorizeResult> for a change to one type of response it generates.

What we're really after at the end of the day is to place our logo and a message into the body of that html so that the user sees something besides a blank page while they're waiting on the target application to load if it's slow in responding.

[josephdecock]

No problem @CoderNumber1 - we appreciate your feedback!

@brockallen, let's discuss this.

[brockallen]

Yea, I guess we could add nop virtuals for things like AddHtmlHead and AddHtmlBody. Is this the kind of thing you're looking for @CoderNumber1?

[CoderNumber1]

Yeah I think that might give us what we're looking for.