Support for private_key_jwt for endpoint authentication? #10438

2 Answer(s)

• 

  0

  AI-Bot created 9 hours ago

  Support Team ABP Agent

  • ABP Commercial doesn’t add a special “private_key_jwt” switch for external OIDC providers in Account Pro’s external login infrastructure. The documented AddOpenIdConnect(...).WithDynamicOptions(...) pattern exposes ClientSecret as a dynamic property, but it’s just a convenience layer over ASP.NET Core’s OpenIdConnectHandler and doesn’t inherently limit you to client-secret auth. There is no verified ABP doc/source that explicitly documents built-in private_key_jwt support for external OIDC token endpoint authentication.

  • Planned support: I can’t confirm any roadmap item from verified sources regarding adding first-class private_key_jwt support to WithDynamicOptions/Account Pro for external OIDC providers. (No verified source available for that.)

  • Recommended approach: implement it at the ASP.NET Core OpenIdConnect layer (events/backchannel) and keep ABP’s external-login flow unchanged.

    1. Register the external provider as usual with AddOpenIdConnect(...).
    2. Keep using Account Pro’s external login UI and (optionally) WithDynamicOptions for string properties like Authority, ClientId, etc.
    3. Implement token request customization to send client_assertion / client_assertion_type instead of client_secret.

    Concretely, in ASP.NET Core OIDC, the token exchange happens inside the handler; the typical integration point is customizing OIDC events to adjust the token request sent to the token endpoint. Your goal is:

    • Remove/ignore client_secret
    • Add:
      • client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
      • client_assertion=<signed JWT>

    ABP-specific pitfalls to watch for (these are the ones that most often break ABP external login, regardless of private_key_jwt):

    • Sign-in scheme must be the external cookie:

  options.SignInScheme = Microsoft.AspNetCore.Identity.IdentityConstants.ExternalScheme;
  

  • Map the subject claim to NameIdentifier (otherwise GetExternalLoginInfoAsync() can end up null or user mapping fails):

  options.ClaimActions.MapJsonKey(System.Security.Claims.ClaimTypes.NameIdentifier, "sub");
  

  • Ensure required claims/scopes for user creation: Account module commonly relies on email for creating/registering external users. Request it if your provider doesn’t include it by default:

  options.Scope.Add("email");
      options.GetClaimsFromUserInfoEndpoint = true;
  

  • Dynamic options: WithDynamicOptions is mainly for binding simple option properties (commonly strings). Your private key material/JWT signing logic typically won’t fit as a simple WithProperty(...) mapping; instead, keep the key in your own storage and use it inside your OIDC event to generate the assertion.

  • Interaction with OpenIddict / ABP auth server:

    • Your external OIDC provider integration is happening in the UI host (Account Web) as an external authentication scheme.
    • Your app’s internal auth (OpenIddict) is separate; ABP will still complete the external login, create/link the IdentityUserLogin record, then issue your own tokens/cookies as usual.
    • So the main “ABP pitfalls” are not about OpenIddict itself, but about making sure the external scheme produces a valid external principal (name identifier, email, etc.) and uses IdentityConstants.ExternalScheme.

  Sources (validated):

  • https://abp.io/docs/latest/modules/account-pro
  • https://oauth.net/private-key-jwt/

  ---

  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

  improwise created 9 hours ago

  ABP support team answer please

  Save Cancel