Many people struggle with setting up ASP.NET Core behind load-balancers and reverse-proxies. This is due to the fact that Kestrel is often used just for serving up the application, whereas the “real HTTP traffic” is happening one hop earlier. IOW the ASP.NET Core app is actually running on e.g. http://localhost:5000 – but the incoming traffic is directed at e.g. https://myapp.com.
This is an issue when the application needs to generate links (e.g. in the IdentityServer4 discovery endpoint).
Microsoft hides the problem when running in IIS (this is handled in the IIS integration), and for other cases recommends the forwarded headers middleware. This middleware requires some more understanding how the underlying traffic forwarding works, and its default configuration does often not work for more advanced scenarios.
Long story short – we added a shortcut (mostly due to popular demand) to IdentityServer that allows hard-coding the public origin – simply set the PublicOrigin property on the IdentityServerOptions. See the following screenshot where I configured the value https://login.foo.com – but note that Kestrel still runs on localhost.
HTH
leastprivilege.com 
Any difference between the PublicOrigin property in v3 and the one in v4?
They serve the same purpose.
Thx.
Maybe not the right place to ask this question, but does the above, i.e. using the load balancer’s/reverse proxy’s address, apply to the list of allowed CORS, redirects and logout redirects as well?
No – it only solves one specific problem
Sorry, my bad. What I meant is that independent of the PublicOrigin property developers should use the load balancer’s address when setting up the allowed CORS, redirect and logout redirect urls, shouldn’t they?
yes
Again, thx.
PublicOrigin is perfect for the IdentityServer side. For a hybrid-flow MVC client in another docker container, how do I setup the back-channel to use http://identity:5000/ and browser redirects to use http://localhost:5000/ ? Is this done with HttpOverrides middleware before OpenIdConnect middleware?
You need a proper DNS infrastructure. Localhost does not work beyond hello world.
Works perfectly except in one case.
In the views that are graciously offered by your team, we have in the HomeController’s the following :
Click here to manage your stored grants.
The ~/grants causes a generation of the wrong URL, http://xxx.com/account/login?returnUrl=%2Fgrants, instead of https://xxx.com/account/login?returnUrl=%2Fgrants
I assume this is because in the configuration of Kestrel it knows it is set up for HTTP and thus generates the URL in http. Is there an option I can set where the IdentityServer overrides this and sets it to HTTPS?
Please open an issue on github.
Found this website because I also have a reverse proxy that handles https for me.
The PublicOrigin works for fixing the links for well-known configuration, but when I intergrate with Azure, the redirect url coming back to Identityserver stays http:// instead of https://
In a reverse problem: When I sent PublicOrigin, the redirect url’s Identityserver returns in its response now have https:// instead of http:// although the clientregistration and the url passed from the client didn’t add https…
If you think this is a bug – please open an issue on github.
Is it worth updating this article to point to the changes in IdentityServer4 4.X that encourage using forwarding headers instead of the PublicOrigin?
good idea. but too lazy.
Could you clarify how to handle that in IdentityServer4 4.X. PublicOrigin is removed property. And links in this article for ForwardedHeadersMiddleware is broken.
https://github.com/IdentityServer/IdentityServer4/issues/4535#issuecomment-647084412