Bug: OAuth Redirect not working from behind Azure FrontDoor

[SiliconOrchid]

Context: Current hosting is currently comprised:

• Azure WebApp (with separate deployment slots for both live & testing)
• Azure Frontdoor
  • primary reason: free/quick/convenient way to provision SSL cert for domain.
  • minor reasons: gives a minor speed-boost because of global MS network (between server and POP); provides readiness for us to potentially spin-up additional geo-located servers, etc should site usage suddenly go wildly popular!

Problem: OAuth redirect from GitHub, back to our service, is failing with "Correlation Error". Our server is determining that it has a different name, to that specified by the callback URL.

This is happening because the OAuth redirect back from GitHub is to "www.prtracker.net", but our webApp is not aware of this hostname - it thinks it is "xyz.azurewebsites.net" (the underlying hostname). The use of "www.prtracker.net" domain is actually a network redirect, from the Azure Frontdoor service.

Initial testing:

• The OAuth login works fine on the testing site, where we redirect directly back to "https://prtrackerweb-test.azurewebsites.net/".
• We have experimented, within GitHub portal, setting the OAuth redirect directly to the host - this works fine as expected.

Next Steps:

• Our scenario is completely mainstream, so it is anticipated that this shouldn't be a unique problem to overcome and that a solution is readily available.
• Given the timescales, if a fix is not quickly identified, it may be that it is sensible to abandon the use of FrontDoor and revert to directly pointing the domain to the webapp.
  • To do this, we will need to arrange an SSL certificate separately.

Error Screenshot:

(note: server error messages were temporarily enabled to obtain this screenshot)

[shahiddev]

So if I understand the issue - the custom domain is bound to the AFD and not to the web app, the redirect uri being sent on the OAuth redirect is to your custom domain but Webapps rejects this because it doesn't map to the webapps name.

Can you confirm the initial redirect to the auth provider includes the correct domain name rather than the azurewebsites.net domain? You should see a 302 from your site to the GH provider in the network traffic and should include the redirect_uri in the query string.

I've seen a similar but not the same issue with WebApps and Application Gateway and we end up re-writing the request & response to change the URLs to ensure the OAuth flow works as expected.

EDIT: digging a little further I think these posts may help - depends a little on your precise setup though https://edi.wang/post/2020/6/29/solving-azure-ad-sign-in-failure-with-azure-front-door https://www.phillipsj.net/posts/using-azure-front-door-with-dotnet-core/

[shahiddev]

Incidentally, you should qualify for a free TLS cert on your custom domain bound directly to WebApp so AFD wouldn't be necessary for your primary reason for using AFD

https://azure.microsoft.com/en-gb/updates/secure-your-custom-domains-at-no-cost-with-app-service-managed-certificates-preview/

[SiliconOrchid]

@shahiddev Thanks for your input and comments 👍

@shahiddev -

• I think you have understand scenario :-).
• Confirming that OAuth redirect was to custom-domain and not the underlying apphost name.
  • Incidentally, we experimented modifying the Redirect URL to that apphost name and the solution worked ok (so concluding nothing wrong with deployed code).
• We (myself, @Layla-P, @CrypticEngima) had seen and read the first article that you suggested (but were unable to apply any guidance - for example, we experimented with "backend host header" setting, without success).
• We tried applying the suggested "options.ForwardedHeaders " lines to the codebase, without success.

---

Following a conference call between myself, @Layla-P , @CrypticEngima and @rickvdbosch :

• We decided that faced with a deadline we have opted to simplify the hosting solution and fall back to a simple webapp service.
• We're currently waiting for DNS updates to ripple out, in order to progress. (previously, we used a CNAME to the "www" subdomain - as we are going direct to the appservice, we have now added an "a" record, to take advantage of apex domain).
• @rickvdbosch has demonstrated a neat way of auto-provisioning "letsencrypt" SSL cert ... https://github.com/sjkp/letsencrypt-siteextension/wiki/How-to-install