AWS负载均衡器后Identity Server与MVC客户端的问题咨询

Hey Stuart, let's work through the common issues you're probably facing here—since you're terminating SSL at your AWS Load Balancer, both your MVC client and IdentityServer are only receiving HTTP traffic internally, which causes mismatches in redirect URLs, callback addresses, and protocol detection that breaks authentication flows. Here's how to fix each piece:

Your backend services (MVC on IIS, IdentityServer on Kestrel) don't know the public-facing HTTPS protocol because the LB handles SSL termination. This means they generate HTTP-based URLs for redirects and callbacks, which don't match the user's actual HTTPS session, triggering authentication errors.

1. Fix IdentityServer4 Protocol Detection on Linux Kestrel #

You need to configure IdentityServer to trust the forwarded headers sent by AWS LB, so it knows to generate HTTPS URLs instead of HTTP.

• Update your IdentityServer's startup code (either Program.cs or Startup.cs depending on your .NET version):

// Configure forwarded headers to trust AWS LB's traffic
builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
    // Replace with your AWS LB's IP address(es) for production; use IPAddress.Any for testing
    options.KnownProxies.Add(IPAddress.Parse("10.0.0.1"));
});

// Add this middleware BEFORE UseRouting()
app.UseForwardedHeaders();

• Double-check your IdentityServer client configuration for the MVC app: ensure RedirectUris and PostLogoutRedirectUris use your public HTTPS URL (e.g., https://your-mvc-client.com/signin-oidc), not the internal HTTP address.

2. Configure MVC Client on Windows IIS #

Your IIS-hosted MVC app also needs to recognize the forwarded HTTPS protocol, and its OIDC settings must point to the correct public URLs.

IIS Web.config Adjustments #

Add a rewrite rule to map the X-Forwarded-Proto header to IIS's internal HTTPS flag:

<system.webServer>
  <rewrite>
    <rules>
      <rule name="Forward HTTPS Protocol" stopProcessing="true">
        <match url="(.*)" />
        <conditions>
          <add input="{HTTP_X_FORWARDED_PROTO}" pattern="https" />
        </conditions>
        <serverVariables>
          <set name="HTTPS" value="on" />
          <set name="SERVER_PORT" value="443" />
        </serverVariables>
        <action type="None" />
      </rule>
    </rules>
  </rewrite>
</system.webServer>

MVC OIDC Client Configuration #

Update your MVC app's authentication setup to use the public HTTPS Authority and handle forwarded headers:

// Enable forwarded header support
builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
});

app.UseForwardedHeaders();

// Configure OIDC authentication
builder.Services.AddAuthentication(options =>
{
    options.DefaultScheme = "Cookies";
    options.DefaultChallengeScheme = "oidc";
})
.AddCookie("Cookies")
.AddOpenIdConnect("oidc", options =>
{
    options.Authority = "https://your-identity-server.com"; // Public HTTPS URL
    options.ClientId = "your-mvc-client-id";
    options.ClientSecret = "your-client-secret";
    options.ResponseType = "code";
    options.SaveTokens = true;
    // Match these to the URLs configured in IdentityServer
    options.RedirectUri = "https://your-mvc-client.com/signin-oidc";
    options.PostLogoutRedirectUri = "https://your-mvc-client.com/signout-callback-oidc";
});

3. Verify AWS Load Balancer Settings #

Make sure your LB is properly forwarding the necessary headers to backend instances:

• For Application Load Balancers (ALB), forwarding X-Forwarded-Proto and X-Forwarded-For is enabled by default, but confirm this in your listener's Forwarding Rules > Advanced Configuration.
• Ensure your backend instances' security groups allow inbound traffic from the LB's IP range on the respective ports (80 for MVC, your Kestrel port like 5000 for IdentityServer).

Quick Troubleshooting Checks #

• Check IdentityServer logs: Look for generated authorization/callback URLs—if they're HTTP instead of HTTPS, your forwarded header setup is missing.
• Inspect browser network requests: Verify the redirect to IdentityServer uses HTTPS, and the callback URL matches what's configured in both services.
• Check MVC app logs: Ensure the OIDC middleware is using the correct HTTPS Authority and RedirectUri.

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