Cross-domain (tenant-per-subdomain) Linked-Account switch with Angular + OpenIddict #10756

1 Answer(s)

• 

  0

  maliming created 3 months ago

  Support Team Fullstack Developer

  Hi,

  1. AbpAccountOpenIddictOptions is the correct one for Angular + OpenIddict.

  AbpAccountOptions.IsTenantMultiDomain / GetTenantDomain are only read by the MVC Razor Pages account flow (and the old IdentityServer path), so they have no effect on a separated OpenIddict auth server. The LinkLogin / SwitchTenant token grants read AbpAccountOpenIddictOptions, which is exactly why configuring that one works for you. It's the right, supported options class here — it's just missing from the docs, and we'll improve the docs for this option.

  Configure<AbpAccountOpenIddictOptions>(options =>
  {
      options.IsTenantMultiDomain = true;
      options.GetTenantDomain = (httpContext, info) =>
          Task.FromResult(/* tenant URL */);
  });
  

  2. The duplicate tenant_domain is a bug, and removing the handler is the right workaround.

  When IsTenantMultiDomain is on, the grant sets tenant_domain on the sign-in AuthenticationProperties. OpenIddict already promotes that into the token response on its own, so the extra LinkLoginExtensionGrantProcessJsonResponse handler adds the same key a second time, and AddParameter throws on the duplicate — that's the HTTP 500. The handler is redundant, which is why removing it keeps tenant_domain in the response and everything works.

  For the affected version, use this as a temporary workaround. If your version registers both handlers, remove both — they both hook the token response and key off the same tenant_domain parameter, so leaving the SwitchTenant one in can still throw on a LinkLogin response:

  using OpenIddict.Server;
  using Volo.Abp.Account.Web.ExtensionGrants;
  
  PreConfigure<OpenIddictServerBuilder>(builder =>
  {
      builder.RemoveEventHandler(LinkLoginExtensionGrantProcessJsonResponse.Descriptor);
      builder.RemoveEventHandler(SwitchTenantExtensionGrantExtensionGrantProcessJsonResponse.Descriptor);
  });
  

  We're removing these redundant handlers in the next release, so once you upgrade to a version that includes the fix you can drop the PreConfigure block.

  3. Passing the token in the URL is the built-in behavior.

  For a cross-subdomain switch the source and target tenants are different origins, so localStorage can't be shared between them. The Angular LinkLoginHandler transfers the token once through the redirect URL, the destination reads it into localStorage, then removes it from the visible URL and reloads. That's the framework's own handler, so there's nothing custom to maintain on your side.

  There isn't a drop-in "more secure" variant in the Angular template. The redirect still passes through the address bar / browser history / any proxy or log in between, so if your security requirements are stricter than that, the only real alternative is a different architecture — a shared cookie on the parent domain, or a backend-for-frontend that keeps the tokens server-side. For the built-in flow, keeping it on HTTPS across your own subdomains is the practical setup.

  Thanks

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel