Public Web Authentication Issue – Register Works but Login Fails #10393

2 Answer(s)

• 

  0

  AI-Bot created 2 days ago

  Support Team ABP Agent

  • In a separate Public Web (MVC/Razor) + separate AuthServer (OpenIddict) setup, the Public Web must be an OpenID Connect client and use its own local cookie for the signed-in session. If the OIDC client/cookie setup is missing or misconfigured, the login UI can appear to work (credentials accepted on AuthServer) but no auth cookie is created in the Public Web, so ICurrentUser.IsAuthenticated stays false.

  • Do this in Public Web (its *.Web project/module), ensuring:

    1. Cookie is the default scheme (this is what populates HttpContext.User/ICurrentUser in the Public Web app).
    2. OpenIdConnect is the challenge scheme (redirects to AuthServer).
    3. Redirect URI matches the Public Web host (e.g. https://localhost:44387/signin-oidc) and is registered in OpenIddict client.
    4. (Common pitfall) Disable calling userinfo unless you really need it (otherwise you can get “login succeeds but no user is established” symptoms depending on token/claims settings).

  Public Web – authentication configuration (example)

  Put/adjust in your Public Web module (e.g. PublicWebModule / YourProjectWebModule) ConfigureServices:

  using Microsoft.AspNetCore.Authentication.Cookies;
  using Microsoft.AspNetCore.Authentication.OpenIdConnect;
  using Microsoft.IdentityModel.Protocols.OpenIdConnect;
  
  private void ConfigureAuthentication(ServiceConfigurationContext context, IConfiguration configuration)
  {
      context.Services.AddAuthentication(options =>
          {
              options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
              options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
          })
          .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme, options =>
          {
              // Optional but recommended in multi-app scenarios:
              options.Cookie.Name = ".YourCompany.PublicWeb.Auth";
          })
          .AddOpenIdConnect(OpenIdConnectDefaults.AuthenticationScheme, options =>
          {
              options.Authority = configuration["AuthServer:Authority"]; // https://localhost:44349
              options.RequireHttpsMetadata = Convert.ToBoolean(configuration["AuthServer:RequireHttpsMetadata"]);
  
              options.ClientId = configuration["AuthServer:ClientId"];         // the PublicWeb client id in OpenIddict
              options.ClientSecret = configuration["AuthServer:ClientSecret"]; // if applicable
              options.ResponseType = OpenIdConnectResponseType.Code;
              options.UsePkce = true;
  
              options.SaveTokens = true;
  
              // IMPORTANT (often fixes “login ok but not authenticated” issues due to userinfo problems)
              options.GetClaimsFromUserInfoEndpoint = false;
  
              options.Scope.Clear();
              options.Scope.Add("openid");
              options.Scope.Add("profile");
              options.Scope.Add("email");
              options.Scope.Add("roles");
          });
  }
  

  AuthServer – OpenIddict client must match Public Web URLs

  In the AuthServer’s OpenIddict client registration (seed/config), ensure the Public Web client has:

  • redirect_uri: https://localhost:44387/signin-oidc
  • post_logout_redirect_uri: https://localhost:44387/signout-callback-oidc
  • Allowed grant type: authorization_code
  • (If using PKCE) PKCE enabled/compatible
  • Scopes include at least openid profile email roles (+ any API scopes you need)

  Why ICurrentUser is empty

  ICurrentUser is populated from the current HTTP request user principal. In an MVC app that comes from the local authentication cookie. If the Public Web app doesn’t issue/receive its own cookie after the OIDC callback, HttpContext.User stays anonymous → ICurrentUser stays empty.

  Recommended way to “share authentication” between Admin/AuthServer and Public Web

  • Don’t try to share the same cookie across apps/domains/ports.
  • Use centralized AuthServer (OpenIddict) + each UI (Admin and Public) is a separate OIDC client with its own cookie.
  • You’ll still get SSO-like behavior because the AuthServer session persists; subsequent logins from the other app typically won’t prompt credentials.

  Sources

  • https://abp.io/docs/latest/solution-templates/layered-web-application/deployment/openiddict-deployment
  • https://abp.io/docs/latest/solution-templates/single-layer-web-application/authentication

  ---

  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 yesterday

  Support Team Fullstack Developer

  hi

  The public website login flow is:

  public website login -> redirect to authserver -> signin authserver -> redirect to public website.

  Now both the public website and the authserver are signed.

  Thanks.

  Save Cancel