反向代理背后的Azure App Service身份验证

Question

I'm working with Authentication in Azure App Service, AKA "Easy Authentication" https://docs.microsoft.com/en-us/azure/app-service/app-service-authentication-overview

It works fine if I browse my azure web-site using it's Azure name: [myid].azurewebsites.net But if place my web-site behind a reverse proxy, after authentication, I'm always redirected to [myid].azurewebsites.net instead of www.[mydomain].com. The reverse proxy is correctly configured to serve my pages and all work fine without authentication.

I think that the root cause is how the redirect_uri parameter is built by "Easy Authentication". Using Chrome F12 I noticed that during the initial redirect to authentication service, the browser url is built using [myid].azurewebsites.net instead of www.[mydomain].com.

https://login.windows.net/034...51/oauth2/authorize?response_type=id_token&redirect_uri=https%3A%2F%2Fmyid.azurewebsites.net%2F.auth%2Flogin%2Faad%2Fcallback& ......

I can't find a way to instruct/force "Easy Authentication" to use www.[mydomain].com

Any suggestions or idea?

--- update ---
I use Nginx as reverse-proxy. The relevant fragment of the configuration file (redacted):

server {
        server_name www.mydomain.com;
        listen 80;
        listen 443 ssl;
        ...
        location / {
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Real-Host $host;
                proxy_pass https://myid.azurewebsites.net/;
        }
}

Answer 1

We need to include an extra parameter to instruct where the process should redirect to after successful authentication. We can do this with the 'post_login_redirect_uri' parameter. Without this, the process will redirect to a default 'Authentication Successful' page with a link to go back to the site.

For more details, refer to this document: https://weblogs.asp.net/pglavich/easy-auth-app-service-authentication-using-multiple-providers .

Answer 2

According to your description, I used URL Rewrite and Azure Functions Proxies as my reverse-proxy to test this issue, I found that I could encounter the same issue as you mentioned. I also tried to compare Headers 、 ServerVariables between accessing via reverse-proxy and directly accessing, and tried to override the related headers to narrow this issue, but failed in the end. I assumed that since we are using the build-in App Service Authentication / Authorization, we could not override the generating for the redirect_uri parameter.

Per my understanding, you could set the additional header(s) under your reverse-proxy, then build the authentication / Authorization in your application to pick up the additional header for generating the redirect_uri and redirect user to the related authorize endpoint. Or you could use Traffic Manager for Load Balancer, and you could follow this issue . Additionally, if you just want to customize your azure web app domain, you could follow here .