New in IdentityServer4 v2: Simplified Configuration behind Load-balancers or Reverse-Proxies

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.

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 – but note that Kestrel still runs on localhost.



This entry was posted in ASP.NET Core, IdentityServer, Uncategorized, WebAPI. Bookmark the permalink.

18 Responses to New in IdentityServer4 v2: Simplified Configuration behind Load-balancers or Reverse-Proxies

  1. Eirik M says:

    Any difference between the PublicOrigin property in v3 and the one in v4?

  2. No – it only solves one specific problem

    • Eirik M says:

      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?

  3. robrich says:

    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?

  4. Patrick says:

    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,, instead of

    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?

  5. 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…

  6. Ryan Mendoza says:

    Is it worth updating this article to point to the changes in IdentityServer4 4.X that encourage using forwarding headers instead of the PublicOrigin?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s