Application Configuration Endpoint Missing Auth Information After Upgrade (7.2.1 → 9.3.6) #10122

8 Answer(s)

• 

  0

  AI-Bot created 21 days ago

  Support Team ABP Agent

  1. Solution Based on ABP’s recent versions and typical causes observed in upgrades, the /api/abp/application-configuration endpoint omits the auth/currentUser info when the request is not recognized as an authenticated call on the API side. In practice, this almost always comes down to bearer-token validation not succeeding in the API. Please verify and apply the following checklist; each step addresses known, verified reasons for this exact symptom after upgrades:

  • Ensure the API validates the incoming JWT for the correct audience
    • If you use JwtBearer authentication, set the Audience to match the access token’s aud claim and/or the audience you configured when issuing tokens.
    • Example:

  services.AddAuthentication().AddJwtBearer(options =>
      {
          options.Authority = configuration["AuthServer:Authority"]; // e.g. https://auth.my-domain.com
          options.RequireHttpsMetadata = true;                       // or false for local dev
          options.Audience = "AdministrationService";                // must match your token’s aud
      });
  

  • Symptom when missing/incorrect: application-configuration returns isAuthenticated = false and grantedPolicies empty even with a token. This is a confirmed, common root cause in ABP (see the support ticket in Sources).

  • If you migrated from IdentityServer to OpenIddict (ABP 8+), align the OpenIddict configuration

    • Validate that the access token’s audience matches the API’s expected audience (as above).
    • If your AuthServer is behind a reverse proxy (Nginx/IIS/Azure), ensure discovery endpoints are HTTPS and consistent:
      • Set the issuer explicitly:

  PreConfigure<OpenIddictServerBuilder>(builder =>
        {
            builder.SetIssuer(new Uri(configuration["AuthServer:Authority"]!)); // https URL
        });
  

  - When terminating TLS at a proxy, either:
    - Forward the scheme correctly (X-Forwarded-Proto) and enable forwarded headers in all apps, or
    - Force scheme to https on the server:
  

  app.Use(async (ctx, next) =>
          {
              ctx.Request.Scheme = "https";
              await next();
          });
  

  - If your backend listens on HTTP and you can’t forward HTTPS, disable the transport security requirement:
  

  if (!Convert.ToBoolean(configuration["AuthServer:RequireHttpsMetadata"]))
        {
            Configure<OpenIddictServerAspNetCoreOptions>(o =>
            {
                o.DisableTransportSecurityRequirement = true;
            });
        }
  

  - Make sure discovery JSON (/.well-known/openid-configuration) returns HTTPS URLs. If it returns HTTP, front-ends (Angular/OIDC libs) will ignore it and no valid token flow will occur.
  

  • Confirm the bearer actually reaches the endpoint

    • In browser dev tools or Swagger, check that Authorization: Bearer <token> is present for the GET /api/abp/application-configuration request.
    • Ensure CORS and CSRF settings aren’t stripping the header for your origin. If you see OPTIONS 204 but the GET is missing the Authorization header, adjust CORS.

  • Multi-tenancy header/host checks (if applicable)

    • If you rely on tenant resolution for permission checks, ensure the tenant resolution works after upgrade (AbpTenantResolveOptions, domain/host mapping, X-Tenant header if you use it). A broken tenant resolution can lead to perceived unauthenticated/unauthorized context.

  • Token issuance scope and client configuration (OpenIddict)

    • Verify your OpenIddictDataSeedContributor grants the scopes the client requests and that the client is allowed to use the authorization/token endpoints and the code flow. Otherwise, the client won’t obtain a valid access token. If you recently switched to OpenIddict, double-check grantTypes, allowed scopes and permissions for your client app.

  • Logging to confirm

    • Enable debug logs for Authentication and OpenIddict on API and AuthServer to see audience/issuer/discovery errors. A typical failure looks like “IDX20803: Unable to obtain configuration…” (means discovery URL mismatch/HTTP vs HTTPS), or validation failing silently leading to unauthenticated context for application-configuration.

  If you implement the audience fix and ensure the discovery/issuer are consistent HTTPS values (or correctly forwarded), the application-configuration endpoint will include:

  • currentUser with isAuthenticated = true and user info
  • auth.grantedPolicies populated

  2. Sources

  • Validated: ABP 9.3 Migration Guide
    • https://abp.io/docs/latest/release-info/migration-guides/abp-9-3
  • Validated: ABP Support case confirming audience misconfiguration causes currentUser/auth empty in application-configuration
    • https://abp.io/support/questions/3303
  • Validated: ABP 9.3 Release info context
    • https://abp.io/community/articles/fw4n9sng

  ---

  This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

  Save Cancel
• 

  0

  maliming created 21 days ago

  Support Team Fullstack Developer

  hi

  Can you share ASP.NET Core debug logs of /api/abp/application-configuration request?

  https://abp.io/support/questions/8622/How-to-enable-Debug-logs-for-troubleshoot-problems

  Thanks.

  Save Cancel
• 

  0

  admin@autosled.com created 21 days ago

  Sure here is my logs file. https://limewire.com/d/nApaM#sqgpwLG4xQ

  Save Cancel
• 

  0

  maliming created 21 days ago

  Support Team Fullstack Developer

  hi

  The log level still seems to be [INF] , can you change the LoggerConfiguration in all places?

  var loggerConfiguration = new LoggerConfiguration()
      .MinimumLevel.Debug()
      .MinimumLevel.Override("Microsoft.EntityFrameworkCore", LogEventLevel.Warning)
      .Enrich.FromLogContext()
      .WriteTo.Async(c => c.File("Logs/logs.txt"))
  

  Can you also share your AdministrationServiceHttpApiHostModule code?

  Thanks.

  Save Cancel
• 

  0

  admin@autosled.com created 21 days ago

  This is my current LoggerConfiguration

  Now I can see that its throwing an error trying to decode the token https://limewire.com/d/5DuRn#LNiCiloDL4

  Not sure if this is usefull but in my IdenityService I have the Microsoft.IdentityModel imported with version 8.14.0

  Save Cancel
• 

  0

  maliming created 21 days ago

  Support Team Fullstack Developer

  hi

  System.MissingMethodException: Method not found: 'Void Microsoft.IdentityModel.Tokens.Base64UrlEncoder.Decode(System.ReadOnlySpan1<Char>, System.Span1<Byte>)'.

  Try to use 8.12.0 package version of IdentityModel

  <PackageReference Include="System.IdentityModel.Tokens.Jwt" Version="8.12.0" />
  <PackageReference Include="Microsoft.IdentityModel.Protocols.OpenIdConnect" Version="8.12.0" />
  <PackageReference Include="Microsoft.IdentityModel.Tokens" Version="8.12.0" />
  <PackageReference Include="Microsoft.IdentityModel.JsonWebTokens" Version="8.12.0" />
  

  Save Cancel
• 

  0

  admin@autosled.com created 21 days ago

  Awesome that did the trick. Thanks so much for you support, insanely fast 👍👍

  Save Cancel
• 

  0

  maliming created 21 days ago

  Support Team Fullstack Developer

  Great news 👍

  Save Cancel