Possible to have multiple public origins for an identity server?

[Greeng0]

I have an environment where my identity server is cloud-hosted, on a server behind a load balancer. So although it is actually hosted at https::5000, my API clients can access it at https://identity.com (which leads to my load balancer) by configuring this uri as the PublicOrigin.

What I would like, is to have two aliases, e.g. https://identity.appone.com and https://identity.apptwo.com, pointing to my load balancer which would still redirect traffic to that same identity server.

As the PublicOrigin only allows a single entry, I wanted to know if there was any other way to achieve this. I would like to avoid the need for two separate identity servers using the same database just to configure two PublicOrigins.

If two identity servers are indeed necessary, would it be possible for my resource-owning client APIs, who are similarly hosted under two aliases behind a load balancer to dynamically choose which identity server to use for authentication, perhaps via some middleware? E.g. the client API receives a request with the origin https://resource.appone.com, and so uses the identity server at https://identity.appone.com?

[brockallen]

You can set it per-request:

https://github.com/IdentityServer/IdentityServer4/blob/master/src/IdentityServer4/src/Extensions/HttpContextExtensions.cs#L29

but you might have different issues once you start doing that. https://openid.net/specs/openid-connect-core-1_0.html#IssuerIdentifier

[leastprivilege]

As Brock points out - two different DNS names also means two logical token issuers.

That said - you should not use public origin at all - it is a hack for incorrectly configured reverse proxies. What you should do is to pick-up the X-Forwarded headers from the load balancer and set the host names dynamically (check the MS docs for the forwarded headers middleware).

[Greeng0]

For future reference, and possibly to help @alancorreas with their issue, I managed to get a working solution:

On the identity server I took @brockallen's suggestion of using the HttpContextExtention to set the origin per request.

On the Resource Owner side, I was able to tweak/trim down the solution from stackoverflow that was posted here, by swapping out the OpenIddictServerOptions for OpenIdConnectOptions. That way I can set the OpenIdConnectOptions.Authority and OpenIdConnectOptions.ClientId based on values in the current request.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.