Identity Server 4验证localhost来源令牌失败问题求助

Ah, I’ve seen this exact issue so many times when folks upgrade from IdentityServer3 to IdentityServer4! The root cause almost always comes down to stricter default validation rules in ID4—specifically around issuer matching or audience configuration—that ID3 didn’t enforce as tightly. Let’s walk through the most likely fixes:

1. Issuer Mismatch (The #1 Cause) #

IdentityServer4 generates the iss (issuer) claim in tokens based on the hostname of the incoming request. Since your UI uses localhost to talk to IdentityServer, the token’s iss will be something like http://localhost:5000. But your API is hitting IdentityServer at 192.168.0.10, so when it pulls the discovery document, it sees the issuer as http://192.168.0.10:5000. ID4’s default validation rejects tokens where these two values don’t line up.

Fix Options: #

• Set a fixed issuer URI in IdentityServer4: Force all tokens to use a consistent issuer value, no matter which hostname is used. Add this to your IdentityServer startup config:

  services.AddIdentityServer(options =>
  {
      // Use a stable identifier (can be a custom name, IP, or DNS entry)
      options.IssuerUri = "http://mypc-identityserver";
  })
  

  Then update your API’s auth setup to validate against this fixed issuer:

  services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
      .AddJwtBearer(options =>
      {
          options.Authority = "http://192.168.0.10:5000";
          options.Audience = "your-protected-api-id";
          options.TokenValidationParameters = new TokenValidationParameters
          {
              ValidIssuer = "http://mypc-identityserver"
          };
      });
  

• Allow multiple valid issuers in the API: If you prefer not to lock down the issuer URI, tell the API to accept both localhost and 192.168.0.10 as valid issuers:

  options.TokenValidationParameters = new TokenValidationParameters
  {
      ValidIssuers = new[] { "http://localhost:5000", "http://192.168.0.10:5000" }
  };
  

2. Audience Configuration Issues #

IdentityServer4 enforces strict audience (aud) validation by default, whereas IdentityServer3 was more lenient. Make sure the audience claim in your token matches what your API expects.

Checks & Fixes: #

• Validate your IdentityServer4 ApiResource setup: Ensure you’ve defined your API resource with the correct ID:

  new ApiResource("your-protected-api-id", "My Protected API")
  

• Confirm the UI requests the right scope: When the UI fetches a token, it must include the API’s scope (e.g., your-protected-api-id) in its request.
• Set the correct audience in the API: Make sure your API’s JwtBearer config specifies the matching audience ID:

  options.Audience = "your-protected-api-id";
  

3. Quick Debugging Tip #

Before tweaking configs, decode the token your UI receives using a JWT inspection tool (like the System.IdentityModel.Tokens.Jwt library in .NET). Check the iss and aud claims—this will instantly tell you if either is mismatched with what your API is validating against.

Bonus: HTTP vs HTTPS Note #

If you’re working in a dev environment with plain HTTP, disable HTTPS metadata validation in your API’s JwtBearer setup (ID4 defaults to requiring HTTPS for production):

options.RequireHttpsMetadata = false;

内容的提问来源于stack exchange，提问作者romeo.Do