Identity Server authorize endpoint redirects to internal hostname

I have…

I’m submitting a…

  • [x] Regression (a behavior that stopped working in a new release)
  • [x] Bug report
  • [ ] Performance issue
  • [ ] Documentation issue or request

Current behavior

After the upgrade from dev-7133 to 7.4.0 /identity-server/.well-known/openid-configuration endpoint was no longer accessible (HTTP 404).

After looking through the Support we stumbled upon this article. After adding IDENTITY__MULTIPLEDOMAINS=true we now have /identity-server/.well-known/openid-configuration working again but /identity-server/connect/authorize endpoint responds with redirect to /identity-server/account/login under wrong domain (internal hostname).

This is our setup:

  • Azure Container App is hosting Squidex docker image under the URL https://<redacted>
  • Azure Front Door is configured with custom domain pointed at https://<redacted>
  • Squidex is configured with base URL set to (see below for the entire config).

Expected behavior


  • /identity-server/.well-known/openid-configuration works without the need for IDENTITY__MULTIPLEDOMAINS=true as we don’t use Squidex under https://<redacted>
  • /identity-server/connect/authorize redirects to /identity-server/account/login under the same domain configured in URLS__BASEURL.

It should also be noted that with IDENTITY__MULTIPLEDOMAINS=true, /identity-server/.well-known/openid-configuration returns JSON object with all URLs correctly containing, e.g.

    "issuer": "",
    "authorization_endpoint": "",
    "token_endpoint": "",
    "introspection_endpoint": "",
    "end_session_endpoint": "",
    "userinfo_endpoint": "",
    "jwks_uri": ""

Minimal reproduction of the problem

On dev-7133:

  1. User goes to
  2. User is redirected to
  3. After providing correct credentials user goes back to


  1. User goes to
  2. Page hangs with request to /identity-server/.well-known/openid-configuration retruning 404.


  1. User goes to
  2. User is redirected to https://<redacted>
  3. After providing correct credentials user goes back to


App Name:

  • [x] Self hosted with docker
  • [ ] Self hosted with IIS
  • [ ] Self hosted with other version
  • [ ] Cloud version

Version: 7.4.0


  • [x] Chrome (desktop)
  • [ ] Chrome (Android)
  • [ ] Chrome (iOS)
  • [ ] Firefox
  • [ ] Safari (desktop)
  • [ ] Safari (iOS)
  • [ ] IE
  • [ ] Edge



    "assetStore": {
        "type": "AzureBlob",
        "azureBlob": {
            "containerName": "<redacted>",
            "connectionString": "<redacted>"
    "eventStore": {
        "mongoDb": {
            "configuration": "<redacted>"
    "contents": {
        "optimizeForSelfHosting": true
    "clustering": {
        "worker": false
    "urls": {
    "baseUrl": "",
    "store": {
        "mongoDb": {
            "configuration": "<redacted>",
            "valueRepresentation": "Document"
    "ui": {
        "onlyAdminsCanCreateApps": true,
        "redirectToLogin": true,
        "map": {
            "googleMaps": {
                "key": ""
        "hideNews": true,
        "hideOnboarding": true,
        "google": {
            "analyticsId": ""
    "notifo": {
        "appId": "",
        "apiKey": "",
        "apiUrl": ""
    "identity": {
        "multipleDomains": true,
        "adminEmail": "<redacted>",
        "adminPassword": "<redacted>",
        "allowPasswordAuth": true,
        "lockAutomatically": true,
        "googleClient": "",
        "googleSecret": "",
        "githubClient": "",
        "githubSecret": "",
        "microsoftClient": "",
        "microsoftSecret": "",
        "microsoftTenant": null,
        "privacyUrl": ""
    "news": {
        "appName": "",
        "clientId": "",
        "clientSecret": ""
    "twitter": {
        "clientId": "",
        "clientSecret": ""
    "templates": {
        "repositories": []
    "logging": {
        "level": "Warning",
        "human": false,
        "colors": false

Right now, I have no idea what could cause this. It works fine for me.

Perhaps the actual host name is not forwarded through the proxies.

Edit: I had a look to the source code of OpenIdDict and I really think that this is the root issue.

Thank you, Sebastian. Your comment about the hostname inspired me to dig deeper and that indeed was the problem.

For anyone on Azure with the similar setup to ours, here’s what happened and how to remedy this.

As per this article:

If the request was made for, and your origin has an empty header field, Front Door will set the host header as

Our Squidex route in Front Door has custom domain and origin group. That origin group points to a Container App. When configuring said group we left the “Origin host header” field as default which Azure auto-populated to <redacted> By setting that field to empty value we have ensured if request is made to, Host header will be set to


I appreciate this is not a support site for Azure so I will keep it brief. You need to be aware that a lot of Azure resources use Host header for routing and/or verification. There’s a very good write up about this here. We opted for solution #1.

1 Like