Open Closed

Azure AD Configuration and Login Issues + Angular #1291

riley.trevillion created
  • ABP Framework version: 4.3.0
  • UI type: Angular
  • DB provider: EF Core
  • Tiered (MVC) or Identity Server Separated (Angular): No
  • Exception message and stack trace: See below
  • Steps to reproduce the issue: See below

<br> Hello

I'm trying to integrate Azure Active Directory as an external login provider for our application which is using the Angular UI. I have followed the instructions in this article ( but I have encountered a number of issues during the setup that I hope you can assist me in resolving.

I have created a fresh copy of the ABP solution to rule out anything specific with our product and I am still able to reproduce the issues in the fresh solution. Either there is a bug or I am misconfiguring something in the app or in Azure AD.

Steps To Reproduce

  1. Set 'admin' as the default role in the ABP application so that new users are automatically assigned that role on creation (achieved by loging in with precreated local admin user)
  2. Register application in Azure AD
  3. Add the following code blocks to HttpApi.Host > [App Name]HttpApiHostModule.cs to enable OpenID connection
  4. Log in with the Azure AD user
  5. Observe that the correct menus for the admin role are present, but the user is not logged in. If you attempt to access any of the menus or application items it will redirect you for authentication briefly and then drop you back at the same page
  6. Some things worth noting
    • I'm aware of the CORS request made for path: /api/abp/application-configuration from origin: http://localhost:4200 but was ignored because path was not for an allowed IdentityServer CORS endpoint error in the provided logs. I have added this origin to the CORS configuration in the database, and it appears to be accessing that origin just fine based on the network logs (see screenshots). I'm not sure whether this is an issue.
    • I cannot log in with the local admin user anymore once the OpenID code has been placed into the solution. It produces the same 'not logged in' state I've described above. The culprit is appears to related to the claim manipulation code blocks that the guide has directed me to include i.e JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear(); JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Add("sub", ClaimTypes.NameIdentifier); I am able to log in with a local user if those code blocks are removed, but if I try and log in with the AzureAD user I just get returned to the login page. I've attached logs of whats going on under the REMOVED JwtSecurityTokenHandler CODE BLOCKS log below.

I've provided as much information as possible to help with diagnosing this issue. It would be good if you are able to confirm the problems I've described on your end with a fresh solution following the reproducability steps I've detailed above. That would help narrow down whether these issues are related to bugs in the solution or if I am misconfiguring something / the article I've followed is no longer accurate for version 4.3.0 and I need to perform additional configuration.

Thank you


REMOVED JwtSecurityTokenHandler CODE BLOCKS LOG:

6 Answer(s)
  • 0
    gterdem created
    Support Team

    I have reproduced the problem. This indeed seems a behavior change.

    I will try to find out the source of this behavior change since Microsoft is making changes to authentication libraries on their side aswell. Here is the related blog post. If it is related with our side, we'll fix it as soon as possible.

  • 0
    riley.trevillion created

    Hi @gterdem

    Thankyou for looking into this one and confirming the reproducability. Do you have any additional updates on the status / progress of your investigation and a potential way forward (bug fix / workaround / configuration) for resolving this one in the short term?

    We have a release planned in the next 1-2 weeks that was expected to include Azure AD integration for our clients. Depending on the complexity of the issue here and an ETA on a fix, my team may need the time period leading up to the release to figure something else out if Azure AD integration is not possible before the end of the month.

    Thankyou again for your help.

  • 0
    gterdem created
    Support Team

    @riley.trevillion <br>

    TLDR: Update OpenIdConnect configuration
    private void ConfigureExternalProviders(ServiceConfigurationContext context, IConfiguration configuration)
            .AddOpenIdConnect("AzureOpenId", "Azure AD OpenId", options =>        {
                options.Authority = "" + configuration["AzureAd:TenantId"] +
                options.ClientId = configuration["AzureAd:ClientId"];
                options.ResponseType = OpenIdConnectResponseType.CodeIdToken;
                options.CallbackPath = configuration["AzureAd:CallbackPath"];
                options.ClientSecret = configuration["AzureAd:ClientSecret"];
                options.RequireHttpsMetadata = false;
                options.SaveTokens = true;
                options.GetClaimsFromUserInfoEndpoint = true;
                options.ClaimActions.MapJsonKey(ClaimTypes.NameIdentifier, "sub");


    Remove static claim mapping

    Don't use JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();.

    Map sub claim manually

    Add options.ClaimActions.MapJsonKey(ClaimTypes.NameIdentifier, "sub"); in your OpenIdConnect configuration

    Ensure AzureAD has email for user

    Since abp uses email claim for auto user registration, email field should not be empty. Otherwise you won't get an error but a page prompting to enter email At the end, sub claim should be mapped and you should have requested and recieved email claim Result:

    Stay tuned for article update.

  • 0
    riley.trevillion created

    Hi @gterdem

    I have been able to log in successfully with Azure AD on both the fresh copy of ABP and our existing solution using the new instructions you have provided. Thankyou!

    There is one fly in the ointment though, unfortunately. If you require users to confirm their email on login (ABP setting), attempting to log in again with the same Azure AD user results in a 'username is already taken' error. If you switch the setting off and users don't need to confirm their emails, the issue doesn't occur.

    Do you have any suggestions on how to resolve this one?

    Thankyou again.

  • 0
    albert created
    Support Team

    closing the issue since the main defect has been resolved. you can create a new ticket for your new questiion. thank you

  • 0
    riley.trevillion created

    Hi @alper

    I've created a new ticket here -'Username-Taken'-on-Subsequent-Logins