How to Authenticate Between Two ABP Web Applications Using OpenID and SSO #10245

1 Answer(s)

• 

  0

  AI-Bot created 3 hours ago

  Support Team ABP Agent

  1. Solution

  • Use Centralized Authentication (one Auth Server) and OIDC sign-in, not password-based token requests:

    • Treat Solution 1 as the single OpenIddict Authorization Server (AuthServer).
    • Register each frontend/back‑end of Solution 2 as OpenIddict client applications on Solution 1.
    • In Solution 2, authenticate users via standard OpenID Connect browser flow (Authorization Code, with PKCE for SPAs if any). Never call the token endpoint with username/password when users come from SSO.

  • Automatic user provisioning on first external login (recommended):

    • ABP’s Account module supports external/third‑party logins and can create a local user automatically on first login when external provider returns required claims (e.g., email). This allows Solution 2 users to appear in Solution 1’s identity store without knowing their password.
    • Ensure your OIDC configuration requests the email scope and maps sub -> NameIdentifier so ABP can provision users.
    • If you must restrict auto‑provisioning, handle the external login callback to apply custom rules or block creation.

  • Don’t reuse the same confidential client credentials across different sites arbitrarily:

    • Create a dedicated client for each app of Solution 2 in Solution 1’s OpenIddict (distinct client_id, secret if confidential, redirect URIs).
    • Register exact redirect URIs and post-logout redirect URIs used by Solution 2.
    • Grant the correct flows: for MVC server-side apps use authorization_code (+ refresh_token); for SPAs use authorization_code with PKCE; avoid resource owner password flow for SSO scenarios.

  • When only email is available (no password):

    • Use OIDC Authorization Code flow. The user authenticates at Solution 1 (AuthServer) using whatever SSO/external IdP it trusts (Azure AD, Google, etc.). Your Solution 2 does not and should not need the user’s password.
    • Ensure Solution 1 returns email and profile claims. In ABP, add options.Scope.Add("email") (and profile) in your OpenIdConnect configuration so the Account module can create/link the user on first login.

  • Practical steps

    1. In Solution 1 (AuthServer):
       • Define API scopes/resources needed by Solution 2.
       • Seed OpenIddict client applications for Solution 2 with:
         • client_id and client_secret (if confidential),
         • allowed grant types: authorization_code (+ refresh_token), optionally PKCE,
         • redirectUris/postLogoutRedirectUris matching Solution 2’s public URLs,
         • scopes: openid, profile, email, offline_access (+ your API scopes).
    2. In Solution 2 (MVC):
       • Add OpenID Connect authentication pointing to Solution 1’s authority:

  services.AddAuthentication()
           .AddCookie()
           .AddOpenIdConnect("oidc", "AuthServer", options =>
           {
               options.Authority = configuration["AuthServer:Authority"];
               options.RequireHttpsMetadata = true;
               options.ClientId = configuration["AuthServer:ClientId"];
               options.ClientSecret = configuration["AuthServer:ClientSecret"];
               options.ResponseType = "code";
               options.UsePkce = true;
               options.SaveTokens = true;
  
               options.Scope.Clear();
               options.Scope.Add("openid");
               options.Scope.Add("profile");
               options.Scope.Add("email");
               options.Scope.Add("offline_access");
               options.Scope.Add("MySolution2Api"); // your API scope(s)
  
               // Important for ABP external login handling:
               options.ClaimActions.MapJsonKey(System.Security.Claims.ClaimTypes.NameIdentifier, "sub");
               options.GetClaimsFromUserInfoEndpoint = true; // or false if you rely on id_token only
           });
  

   - Ensure cookies are configured and the app uses the OIDC challenge for sign-in.
  

  3. Enable ABP external login auto‑provisioning behavior:
     • With email scope present, ABP’s Account module can create the user locally on first login. If you’ve customized login, keep the mapping for sub → NameIdentifier and ensure email is present.
  4. If you run behind reverse proxies/ingress:
     • Register HTTPS redirect URIs that exactly match the browser-facing URLs.
     • Enable forwarded headers so ASP.NET Core and OIDC handlers generate correct https URLs.

  • Summary answers to your questions
    • Recommended approach: Centralized authentication via Solution 1 as AuthServer; Solution 2 signs in via OIDC Authorization Code flow. No password needed.
    • Auto-provision users in Solution 1? Yes, recommended. ABP supports creating the user on first external login if required claims are provided.
    • Specific flow when only email is available? Authorization Code flow (with PKCE for SPA). Request email scope so ABP can provision/link the user.
    • Handling authentication without credentials due to SSO: Never use ROPC or call token endpoint with username/password. Always use browser-based OIDC flow against the central AuthServer; rely on claims and ABP’s external login user provisioning.

  2. Sources

  • Centralized authentication and external IdPs with ABP (validated):
    • https://documentation.openiddict.com/
    • https://github.com/abpframework/abp
  • Community guides showing ABP OIDC external login, scopes and mapping:
    • https://learn.microsoft.com/en-us/aspnet/core/security/authentication/social/?view=aspnetcore-8.0

  ---

  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