I have a webapp which uses IdentityServer for authentication. It's an ASP.NET Core webapp and I'm running Docker on Windows.
I'm facing a problem with the correct URL to use for the challenge response.
My setup involves 2 containers - one for the webapp (let's call it webapp.host) and one for the identity server (is.host)
I put the URL for the identity server in a config file in my webapp. However, here I have a problem. My web app needs to talk to the identity server directly, for example, to access the .well-known/openid-configuration endpoint. For container-to-container access, Docker sets up a network such that webapp.host can find the identity server at is.host/.well-known/openid-configuration.
However, when Identity Server requires a challenge to be made, the webapp ends up trying to redirect the user to is.host/connect/authorize. From the point of view of my browser, however, this is no good - my local machine does not know where is.host is, it only has access to the identity server through an exposed port mapped to localhost.
I'm not sure how to best solve this problem. Is there one name that I can refer to when attempting to access the Identity Server that works from my local browser and also from my webapp's container? Or is it somehow possible to configure Identity Server to work with 2 names?
I noticed that if I access is.host/.well-known/openid-configuration from the webapp container it reports that the authorization_endpoint is is.host/connect/authorize, but that if I access localhost:9002/.well_known/openid-configuration, where localhost port 9002 is mapped to port 80 of is.host, then it reports the authorization_endpoint as localhost:9002/connect/authorize, leading me to believe it is using the request to determine what the correct URL to use is. Should I be overriding this somehow?