Identity Server authorize endpoint redirects to internal hostname

Support
1

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>.azurecontainerapps.io.
  • Azure Front Door is configured with custom domain https://mydomain.com pointed at https://<redacted>.azurecontainerapps.io.
  • Squidex is configured with base URL set to https://mydomain.com (see below for the entire config).

Expected behavior

Either:

  • /identity-server/.well-known/openid-configuration works without the need for IDENTITY__MULTIPLEDOMAINS=true as we don’t use Squidex under https://<redacted>.azurecontainerapps.io.
  • /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 https://mydomain.com, e.g.

{
    "issuer": "https://mydomain.com/",
    "authorization_endpoint": "https://mydomain.com/identity-server/connect/authorize",
    "token_endpoint": "https://mydomain.com/identity-server/connect/token",
    "introspection_endpoint": "https://mydomain.com/identity-server/connect/introspect",
    "end_session_endpoint": "https://mydomain.com/identity-server/connect/logout",
    "userinfo_endpoint": "https://mydomain.com/identity-server/connect/userinfo",
    "jwks_uri": "https://mydomain.com/identity-server/.well-known/jwks"
}

Minimal reproduction of the problem

On dev-7133:

  1. User goes to https://mydomain.com.
  2. User is redirected to https://mydomain.com/identity-server/account/login.
  3. After providing correct credentials user goes back to https://mydomain.com.

On 7.4.0 without IDENTITY__MULTIPLEDOMAINS:

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

On 7.4.0 with IDENTITY__MULTIPLEDOMAINS=true:

  1. User goes to https://mydomain.com.
  2. User is redirected to https://<redacted>.azurecontainerapps.io/identity-server/account/login.
  3. After providing correct credentials user goes back to https://mydomain.com.

Environment

App Name:

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

Version: 7.4.0

Browser:

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

Others:

Config:

{
    "assetStore": {
        "type": "AzureBlob",
        "azureBlob": {
            "containerName": "<redacted>",
            "connectionString": "<redacted>"
        }
    },
    "eventStore": {
        "mongoDb": {
            "configuration": "<redacted>"
        }
    },
    "contents": {
        "optimizeForSelfHosting": true
    },
    "clustering": {
        "worker": false
    },
    "urls": {
    "baseUrl": "https://mydomain.com",
    },
    "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
    }
}
2

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

3

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.

4

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 www.contoso.com, and your origin contoso-westus.azurewebsites.net has an empty header field, Front Door will set the host header as www.contoso.com.

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>.azurecontainerapps.io. By setting that field to empty value we have ensured if request is made to https://mydomain.com, Host header will be set to mydomain.com.

However!

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