AspNetCore Azure AD Connect Callback URL is http, not https
Asked Answered
C

1

13

I have a AspNet Core 2.0 App which authorizes users with Azure AD using the OpenIdConnect API. The callback uris of the Azure App Entry are defined as https://localhost:44369/signin-oidc and https://domain.tld/signin-oidc. When I deploy my app on localhost with IIS Express everything works fine and I can authenticate users correctly.

When I deploy my app to a Linux system with Nginx configured as a reverse proxy to the app authentication doesn't work. Azure AD shows the following error message:

AADSTS50011: The reply address 'http://domain.tld/signin-oidc' does not match the reply addresses configured for the application. More details: not specified

Obviously my app tells Azure AD to redirect back to the http address and Azure AD refuses to do so (fortunately). I guess the problem is that my app thinks it uses http because it listens on http://localhost:5000/ for the reverse proxy.

public void Configure(string name, OpenIdConnectOptions options)
{
    options.ClientId = _azureOptions.ClientId;
    options.Authority = $"{_azureOptions.Instance}{_azureOptions.TenantId}";
    options.UseTokenLifetime = true;
    options.CallbackPath = _azureOptions.CallbackPath;
    options.RequireHttpsMetadata = true;
}

This is the code I use to configure OpenIdConnect. Specifying an absolute path for CallbackPath yields in an exception. Is there any other way to tell OpenIdConnect to allways use https for the CallbackPath?

In case my Nginx is not configured correctly this is part of my configuration:

location / {
        # redirect to ASP.NET application
        proxy_pass         http://localhost:5000;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection keep-alive;
        proxy_set_header   Host $http_host;
        proxy_cache_bypass $http_upgrade;
}

Any help is highly appreciated!

Corrade answered 21/3, 2018 at 13:25 Comment(2)
Is this answer what you are looking for? stackoverflow.com/a/44907445Shornick
Azure B2C is also affected by this, when placed behind an Nginx reverse-proxy pointing at a Linux-hosted AspNet Core 2.1 application. The reply URL generated is HTTP instead of HTTPS. Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectHandler ... Message contains error: 'redirect_uri_mismatch', error_description: 'AADB2C90006: The redirect URI ... provided in the request is not registered for the client idMosul
M
19

I found a linked question with a post that solved this problem. The post instructed the following insertion prior to app.UseAuthentication();

    var fordwardedHeaderOptions = new ForwardedHeadersOptions
    {
        ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
    };
    fordwardedHeaderOptions.KnownNetworks.Clear();
    fordwardedHeaderOptions.KnownProxies.Clear();

    app.UseForwardedHeaders(fordwardedHeaderOptions);

Couple this with your Nginx configuration; it must forwarding this information:

        #
        # Proxy WEB
        #
        location / {
                proxy_pass http://<snip>;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection keep-alive;
                proxy_set_header Host $http_host;
                proxy_cache_bypass $http_upgrade;
                proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header   X-Forwarded-Proto $scheme;
        }

To be thorough, I had already tried forwarding header information, to no avail. These two lines did the trick:

fordwardedHeaderOptions.KnownNetworks.Clear();
fordwardedHeaderOptions.KnownProxies.Clear();

Kudos to charlierlee over in this post.

Mosul answered 9/10, 2018 at 14:27 Comment(3)
Thanks, after making the changes above I was able to login, then started to get signin-oidc 502 bad gateway, following advice in medium.com/@mshanak/… its all workingJemadar
In my testing with nginx, it helped to configure only XForwardedProto and not XForwardedFor. No need to clear anything, which I suspect can lead to other problems. Source: github.com/aspnet/Security/issues/1702#issuecomment-377396765Floristic
Thank you so much i fixed my prep problemSnuffle

© 2022 - 2024 — McMap. All rights reserved.