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 https://edi.wang/signin-oidc.
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.
Solution
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!
Tom Styles
Thanks for this clear and easy to follow explanation of how to fix the issue. Saved me hours of banging my head against app service and front door. Your work is much appreciated.
kalapala sai kalyan
Hello edi wang. Thanks for the great article. Tried to resolve the issue as u mentioned but gone in vain. PLease help me out. When more than 1 web app sits behind the front door however, I was seeing the page not rendering correctly, giving different versions of the page. Also when the authentication and authorisation is enabled, the frontdoor URL is exposing or redirecting to the backend pool (webapps) URL. Also when the authentication and authorisation is enabled, the frontdoor URL is exposing or redirecting to the backend pool (webapps) URL.
Nitin kamble
Thank you for this amazing blog... I have one more request, i need to redirect the user to custom page after non successful authentication by azure AD.is it possible Please reply on my email id if possible nitin.1704k@gmail.com
Tim
Brilliant, thanks!
Len
Hi Edi, have you tried to proxying IPv6 with AFD to the web app (IPv4) If SSO would still work?
Vitali Karmanov
Hey Edi, Thank you for posting this! When I remove the host header and leave it empty, for some reason the application starts returning a 404. Do you have any suggestions or ideas of how to fix this? Thank you!
vijit deshmukh
Hi, We tried the above option, but once Origin Host Header kept blank. Azure FD URL is giving error 404. Can you help me on this
Michael Williams
Thank you so much for writing this... Was driving me NUTS.
qb
Amazing. Thanks