Sign in with azure using tenant domain resolver #10460

5 Answer(s)

• 

  0

  AI-Bot created 19 days ago

  Support Team ABP Agent

  • This is not something you can reliably “work around in code” on the ABP side, because the invalid redirect_uri is enforced by Microsoft (Azure AD): the redirect_uri sent in the OIDC request must exactly match one of the redirect URIs registered for the Azure AD app.
  • Since each tenant uses a different subdomain (tenant1.app.mydomain.com), Azure AD will see a different redirect_uri than app.mydomain.com and reject it unless it is registered.

  What you can do (ABP-supported approach): use wildcard subdomain support on the ABP/OpenIddict side (for ABP’s own AuthServer/OpenIddict validations), but note it does NOT remove Azure AD’s redirect URI requirement.

  Option A (Recommended): Use a single, central redirect URI domain for the Microsoft login callback

  1. Register one redirect URI in Azure AD, e.g.
     • https://app.mydomain.com/signin-oidc (or whatever your callback path is)
  2. Always perform the external login callback on that host (the “root” / central host).
  3. After the callback completes, redirect the user back to the tenant domain, carrying tenant info (e.g., in a returnUrl or parameter) so ABP can resolve the tenant again.

  This keeps Azure AD redirect URIs fixed and avoids registering per-tenant subdomains.

  Option B: If you are using ABP AuthServer/OpenIddict and get invalid redirect_uri there (not Azure)

  If the invalid redirect_uri is coming from ABP’s OpenIddict/AuthServer (common in multi-tenant domain setups), enable ABP’s wildcard-domain support so ABP accepts tenant subdomains without seeding each one:

  In your AuthServer module PreConfigureServices:

  using Volo.Abp.OpenIddict.WildcardDomains;
  
  public override void PreConfigureServices(ServiceConfigurationContext context)
  {
      var configuration = context.Services.GetConfiguration();
  
      PreConfigure<AbpOpenIddictWildcardDomainOptions>(options =>
      {
          options.EnableWildcardDomainSupport = true;
          options.WildcardDomainsFormat.Add("https://{0}.app.mydomain.com");
          // add other app formats if needed
      });
  }
  

  And configure tenant domain resolving:

  using Volo.Abp.MultiTenancy;
  
  Configure<AbpTenantResolveOptions>(options =>
  {
      options.AddDomainTenantResolver("{0}.app.mydomain.com");
  });
  

  This prevents having to seed redirect URIs per-tenant for ABP/OpenIddict.
  However, again: Azure AD still requires exact redirect URIs (so Option B alone won’t solve the Azure AD registration limitation).

  ---

  Links (verified):

  • https://abp.io/docs/latest/guides/ms-multi-tenant-domain-resolving
  • https://abp.io/community/articles/v9y8da7v

  ---

  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 19 days ago

  Support Team Fullstack Developer

  hi

  tenant1.app.mydomain.com does not work after returning from microsoft login to our app

  What are the error logs in your app?

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

  Thanks.

  Save Cancel
• 

  0

  rcalv002 created 18 days ago

  It doesn't get back to the app because of the URI issue, so what we need to figure out is how to have domain tenant resolver enabled, and not have to create a new redirect URI (tenantx.app.mydomain.com) every time in our azure app for every new tenant. Is it possible to have it always come back to app.mydomain.com and go from there?

  [10:27:38 INF] Executing endpoint '/Account/Login'
  [10:27:38 INF] Route matched with {page = "/Account/Login", action = "", controller = "", area = ""}. Executing page /Account/Login
  [10:27:38 INF] Skipping the execution of current filter as its not the most effective filter implementing the policy Microsoft.AspNetCore.Mvc.ViewFeatures.IAntiforgeryPolicy
  [10:27:38 INF] Executing handler method Volo.Abp.Account.Public.Web.Pages.Account.LoginModel.OnPostExternalLogin - ModelState is Invalid
  [10:27:38 INF] Executed handler method OnPostExternalLogin, returned result Microsoft.AspNetCore.Mvc.ChallengeResult.
  [10:27:38 INF] Executing ChallengeResult with authentication schemes (["Microsoft"]).
  [10:27:38 INF] AuthenticationScheme: Microsoft was challenged.
  [10:27:38 INF] Executed page /Account/Login in 9.9514ms
  [10:27:38 INF] Executed endpoint '/Account/Login'
  [10:27:38 INF] Request finished HTTP/1.1 POST https://tenant1.app.mydomain.com/Account/Login?returnUrl=https%3A%2F%2Ftenant1.app.mydomain.com%2F%3Fpage%3D%252FAccount%252F~%252FAccount%252FLogin&handler=ExternalLogin - 302 0 null 27.1038ms
  

  Save Cancel
• 

  0

  AI-Bot created 18 days ago

  Support Team ABP Agent

  • You can’t solve this in ABP code if the error you see is from Azure AD (“redirect_uri is invalid”). Azure AD requires the redirect_uri in the authentication request to exactly match one of the redirect URIs configured in the App Registration. With per-tenant subdomains, the redirect URI becomes https://tenant1.app.mydomain.com/..., so Azure rejects it unless you register each tenant subdomain (which is what you want to avoid).

  • What ABP can do is:

    1. Keep tenant resolving by subdomain enabled (DomainTenantResolver), and
    2. Force the external login callback (redirect_uri) to always use the host/root domain (e.g. app.mydomain.com) so Azure AD only needs one redirect URI.

  1) Solution (single root redirect for Microsoft login)

  Goal: even when the user starts login at https://tenant1.app.mydomain.com, the OIDC redirect_uri sent to Microsoft should be https://app.mydomain.com/signin-oidc (or your configured callback path).

  1. Register only one Redirect URI in Azure AD, for example:

     • https://app.mydomain.com/signin-oidc (typical OIDC callback path)

  2. In your ASP.NET Core/ABP host (Blazor Server), override the redirect URI that the Microsoft handler uses by handling OnRedirectToIdentityProvider:

  using Microsoft.AspNetCore.Authentication.OpenIdConnect;
  using Microsoft.IdentityModel.Protocols.OpenIdConnect;
  
  context.Services.Configure<OpenIdConnectOptions>("Microsoft", options =>
  {
      options.Events ??= new OpenIdConnectEvents();
  
      options.Events.OnRedirectToIdentityProvider = ctx =>
      {
          // Force Azure AD redirect_uri to always be the root domain callback:
          // Adjust path if your callback differs.
          var fixedRedirectUri = "https://app.mydomain.com/signin-oidc";
  
          ctx.ProtocolMessage.RedirectUri = fixedRedirectUri;
  
          // Optional but recommended: keep which tenant initiated the login,
          // so after callback you can redirect back to tenant domain.
          // One common way is to put tenant info into 'state' (OIDC will roundtrip it).
          // If you already have returnUrl, it's typically already round-tripped by ABP/account flow.
          //
          // ctx.ProtocolMessage.State = ... (only if you know exactly what you're doing)
  
          return Task.CompletedTask;
      };
  });
  

  3. After the callback hits app.mydomain.com, redirect the user back to the tenant domain (e.g. by returnUrl). In your log, you already have:

  • returnUrl=https%3A%2F%2Ftenant1.app.mydomain.com%2F... So using a fixed callback host is compatible with “going back to the tenant” as long as your login flow preserves/uses the returnUrl.

  This approach avoids registering tenant-specific redirect URIs in Azure AD entirely.

  ---

  2) Important note: ABP wildcard domain support is for ABP/OpenIddict (not Azure AD)

  If you ever see invalid redirect_uri coming from your own auth server/OpenIddict side, ABP’s wildcard-domain support helps there (so you don’t need to seed every tenant redirect URI into OpenIddict). But it does not change Azure AD’s redirect URI rules.

  To enable ABP wildcard support (useful in OpenIddict/AuthServer scenarios):

  using Volo.Abp.OpenIddict.WildcardDomains;
  
  public override void PreConfigureServices(ServiceConfigurationContext context)
  {
      PreConfigure<AbpOpenIddictWildcardDomainOptions>(options =>
      {
          options.EnableWildcardDomainSupport = true;
          options.WildcardDomainsFormat.Add("https://{0}.app.mydomain.com");
      });
  }
  

  3) Tenant domain resolving stays enabled

  Keep your domain tenant resolver as-is:

  using Volo.Abp.MultiTenancy;
  
  Configure<AbpTenantResolveOptions>(options =>
  {
      options.AddDomainTenantResolver("{0}.app.mydomain.com");
  });
  

  ---

  References

  • https://abp.io/docs/latest/guides/ms-multi-tenant-domain-resolving
  • https://abp.io/community/articles/v9y8da7v

  ---

  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 18 days ago

  Support Team Fullstack Developer

  hi

  This is a limitation of Azure AD. If it doesn't support wildcards or has a limit on the number, there's nothing we can do about it.

  You may consider using a fixed redirect URL and then sharing cookies between all tenant websites. After the host website logs in, it has a TenantId. The tenant website is also logged in. https://abp.io/community/articles/how-to-share-the-cookies-between-subdomains-jfrzggc2

  Thanks.

  Save Cancel