Docker部署的.NET Core 2.0网站经NGinX反向代理对接Azure AD认证遇阻

Hey there! Let's work through getting your Azure AD auth set up correctly for your .NET Core 2.0 app behind an Nginx reverse proxy in Docker. I’ve tackled similar setups before, so here’s a step-by-step breakdown of the most common issues and fixes:

When your app sits behind a reverse proxy like Nginx, it only sees the internal HTTP traffic from the proxy—not the actual HTTPS request from users. This breaks Azure AD auth because the app will generate HTTP callback URLs, which don’t match the HTTPS URIs you registered in Azure.

Here’s how to fix it:

• In your Startup.cs, add forwarded headers configuration before setting up authentication:

  // Inside ConfigureServices method
  services.Configure<ForwardedHeadersOptions>(options =>
  {
      options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
      // Trust your Nginx container's IP or the entire Docker shared network subnet
      // Example: If your Docker network uses 172.18.0.0/16, add this:
      options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("172.18.0.0"), 16));
      // Or trust the specific Nginx container IP:
      // options.KnownProxies.Add(IPAddress.Parse("172.18.0.2"));
  });
  

• Then, in the Configure method, call UseForwardedHeaders() before UseAuthentication():

  app.UseForwardedHeaders();
  app.UseAuthentication();
  app.UseMvc();
  

Make sure Nginx is passing the right headers to your .NET app so it knows the original request details. Update your Nginx location block (the one that forwards traffic to the .NET container) to include these lines:

location / {
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $host;
    # Use your .NET container's name (from Docker shared network) instead of IP
    proxy_pass http://your-dotnet-container-name:5000;
}

• X-Forwarded-Proto tells the .NET app the original request was HTTPS
• Host ensures the app uses the correct domain name for Azure AD callbacks

This is where most auth issues happen—tiny mismatches break everything:

• Redirect URI: Must be the public HTTPS URL users visit, e.g., https://your-domain.com/signin-oidc (never use http://localhost:5000 or internal container URLs)
• Logout URI: Similarly, set this to https://your-domain.com/signout-callback-oidc
• App Configuration: Verify your appsettings.json has the correct Azure AD values:

  "AzureAd": {
      "Instance": "https://login.microsoftonline.com/",
      "Domain": "your-tenant-domain.onmicrosoft.com",
      "TenantId": "your-tenant-guid",
      "ClientId": "your-app-client-guid",
      "CallbackPath": "/signin-oidc",
      "SignedOutCallbackPath ": "/signout-callback-oidc"
  }
  

Even if your app works without auth, it’s worth verifying:

• Both containers are in the same shared Docker network: Run docker network inspect your-network-name to check if both containers are listed
• The .NET container’s 5000 port is accessible from Nginx: Exec into the Nginx container and run curl http://your-dotnet-container-name:5000—you should get a valid response

• "Redirect URI mismatch": This means your app is generating HTTP callbacks. Fix the forwarded headers in .NET Core and Nginx.
• "Invalid issuer": Double-check your TenantId and Instance in appsettings.json—forwarded headers might be causing the app to use the wrong host.
• 403 Forbidden after login: Ensure your Azure AD app registration has the correct API permissions, and your .NET app’s authorization policies are set up to allow authenticated users.

内容的提问来源于stack exchange，提问作者Captainlonate