Today I am migrating my blog to use Azure Front Door which I have introduced in a previous blog post last year. Everything went well except for the blog admin sign in. I configured my blog to Azure AD as SSO. But after I put the blog behind Azure Front Door with my custom domain, OIDC Redirect URL just blow up.
OIDC Redirection Failure
When I tried to sign in, the redirection URL suddenly went to
https://ediwang-web.azurewebsites.net/signin-oidc and blows the application to hell. This is the Azure App Service default domain which is also configured as backend pool in Azure Front Door.
Normally, it should be
The reason Azure AD will redirect back to my Azure App Service domain instead of my custom domain is because Azure Front Door is just doing a simple forward for incoming requests. When the requests hit the App Service, it sees the host header as
*.azurewebsites.net, then, it pass the information to Azure AD, which will use the host header as OIDC redirection URL, it certainly is not my custom domain, so the sign in would fail.
The problem is that we don't have a correct host header to pass to Azure AD, so how can we tell Azure Front Door to use a correct header?
Actually, it's quite simple. By default, when we add a backend pool into Azure Front Door for an App Service, there is a "Backend host header" field automatically filled with the same host name as your website.
Its description is: "The host header value sent to the backend with each request. If you leave this blank, the request hostname determines this value. Azure services, such as Web Apps, Blob Storage, and Cloud services, require this host header value to match the target host name by default."
So, we just must leave this field blank. We can do this by editing an existing backend pool.
Open the backend pool for edit, in my case, its "appservice-edi-wang".
Click the entry in "BACKENDS"
And delete the content in "Backend host header", leave it blank.
Save the changes, and the Azure AD sign in will work again in a few minutes!