Base solution for your next web application
Ends in:
01 DAYS
01 HRS
01 MIN
01 SEC
Open Closed

Azure AD authentication with OpenID Connect: not working as expected?? #6941


User avatar
0
smastro created

Hi,

I've configured OpenID Connect in the appsettings.json, I've my app service registered with Azure Active Directory (AAD from now on) and when I try to sign in using OpenID I'm facing the problem I describe below. I'd like to comment that I'm not necessarily suggesting that there's something wrong in ASP.NET Zero, but it could be the case that due to the sum of different conditions, the integration isn't working as it should.

Could anyone suggest a possible solution to this problem please? I've not been yet able to manage to use Azure AD to sign in even once. Any help would be appreciated!! Thanks.

Description of the problem:

I'm using ver. 6.9.0, template is Angular + ASP.NET Core, openid is as follows:

    "OpenId": {
      "IsEnabled": "true",
      "ClientId": "xxxxx",
      "Authority": "https://login.microsoftonline.com/{tentantID}/v2.0", //<-- v2 endpoint
      //"Authority": "https://login.microsoftonline.com/{tentantID}",      //<-- v1 endpoint
      "LoginUrl": "https://login.microsoftonline.com/{tentantID}/oauth2/v2.0/authorize", //<-- v2 endpoint
      //"LoginUrl": "https://login.microsoftonline.com/{tentantID}/oauth2/authorize", //<-- v1 endpoint
      "ValidateIssuer": "false"
    }

(You'll see why I have 2 Authority and LoginUrl values in a second)

[Problem #1]
  1. When I use AAD's v1.0 endpoint I get an excpetion thrown in the browser by Angular's OIDC library, complaining about a "Wrong Issuer" (even though "validateIssuer" is set to false in appsettings.json.

I've narrowed down the problem to Angular's angular-oauth2-oidc.js file which is trying to compare the "authority" endpoint against the issuer reported by the OpenID Connect response. For some reason Azure is returning a issuer which doesn't match the "authority" endpoint who served the response. It returns this https://sts.windows.net/{tenantID}/ that clearly doesn't match this https://login.microsoftonline.com/{tentantID}

Now, this issue or incompatibliity between Angular and Azure seems to be somewhat known, since I've found this issue here which would address the problem, unfortunately the solution implemented by @ismailcagdas here has not been adopted by Angular (the file angular-oauth2-oidc.js in my system doesn't have that the skipIssuerCheck implemented).

[Problem #2]
  1. When I use AAD's v2.0 endpoint, I get a totally different problem. This time around, the issuer seems to match the endpoint's URI in the ID_token returned by the endpoint, but apparently ASP.NET Zero is expecting some claims that are not sent in the response.
  • The logs show this:
System.InvalidOperationException: Sequence contains no matching element
   at System.Linq.Enumerable.First[TSource](IEnumerable`1 source, Func`2 predicate)
   at Abp.AspNetZeroCore.Web.Authentication.External.OpenIdConnect.OpenIdConnectAuthProviderApi.GetUserInfo(String token)
   at {MyApp}.Web.Controllers.TokenAuthController.GetExternalUserInfo(ExternalAuthenticateModel model) in {PathToRepo}\aspnet-core\src\{MyApp}.Web.Core\Controllers\TokenAuthController.cs:line 455
  • I don't have acces to that code since Abp.AspNetZeroCore.Web it's not shared, but it seems it's expecting some claims that Azure isn't sending.

  • A quick inspection at the 2 JWT (from v1 and v2) shows there are a number of different claims that are gone, in particular, claims that expose user info such as "name", "upn", "unique_name" and many others.

  • Inspecting MS docs, I've found here that they are no longer sending user info unless you add more scopes into the request: i.e., sending scope=openid won't expose user data unless you also pass email and/or profile as part of the scope (scope=openid email profile).

    Historically, the most basic OpenID Connect sign-in flow with Microsoft identity platform would provide a lot of information about the user in the resulting id_token. The claims in an id_token can include the user's name, preferred username, email address, object ID, and more. The information that the openid scope affords your app access to is now restricted. The openid scope will only allow your app to sign in the user and receive an app-specific identifier for the user. If you want to get personal data about the user in your app, your app needs to request additional permissions from the user. Two new scopes, email and profile, will allow you to request additional permissions.

  • I tried editing getOpenIdConnectConfig function @ \angular\src\account\login\login.service.ts changing the scope to include those mentioned above. Azure's response's JWT indeed then added more claims with user data, however I'm still getting the same exception from ASP.NET Zero (System.InvalidOperationException: Sequence contains no matching element).

  • My guess is that ASP.NET Zero expects to use a claim that is no longer sent?

Here's a comparison of JWT's payload section in v1 and v2 (with additional scopes added email and profile), see how some claims are clearly missing, notably unique_name, upn, onprem_sid, ipaddr, and so on... Chances are the code in Abp.AspNetZeroCore.Web is indeed using some of those...

v1.0 Endpoint
{
  "aud": "xxx",
  "iss": "https://sts.windows.net/xxx/",
  "iat": 1556648537,
  "nbf": 1556648537,
  "exp": 1556652437,
  "aio": "AVQAq/8LAAAAzBDj8fFwe5p6kX2H3iQuUjcUekgRffW3vuhyQRN+OQy/mE3/375D+Br2JjBS3PI3dq4n9cE5skVWPmvrsPcKhCXptXCvPrbe/QFddA1ITTI=",
  "amr": [
    "pwd",
    "mfa"
  ],
  "family_name": "xxx",
  "given_name": "xxx",
  "ipaddr": "xxx",
  "name": "xxx",
  "nonce": "jeM5nmDS4zVlgXxG7Qs9TfJavI9OQKeXt1qKsbqD",
  "oid": "xxx",
  "onprem_sid": "xxx",
  "sub": "xxx",
  "tid": "xxx",
  "unique_name": "xxx",
  "upn": "xxx",
  "uti": "xq4QV7nQF0iDJMNr3x8dAA",
  "ver": "1.0"
}
v2.0 Endpoint
{
  "aud": "xxx",
  "iss": "https://login.microsoftonline.com/xxx/v2.0",
  "iat": 1556763507,
  "nbf": 1556763507,
  "exp": 1556767407,
  "aio": "AWQAm/8LAAAA+byyv8Tt3NU1c15gP5GHPSXvkw3ocbo5wS7VBZ4aPiA8esCXtyZyo8LCWpcEhSq54ChVXG5Mi/lef9A2SoCS71JDYkkLcN+0M17ETe5YKzJOFvfJwBSFwWXyhBJ6rpvx",
  "email": "xxx",
  "name": "",
  "nonce": "AQt91n5tSBS1Kl74efN85l90Zga8FRfLVw84TSSu",
  "oid": "xxx",
  "preferred_username": "xxx",
  "sub": "xxx",
  "tid": "xxx",
  "uti": "cSlHfCfDg0Kg3bvx2iM8AA",
  "ver": "2.0"
}

7 Answer(s)
  • User Avatar
    0
    ismcagdas created
    Support Team

    Hi @smastro

    It seems like the problem is unique_name claim. We will fix this problem in v7 in a short time, thank you for reporting it.

    Please follow this issue,

    Thanks,

  • User Avatar
    0
    anissov created

    Hi @ismcagdas any update regarding this issue? I am facing the same problem!

  • User Avatar
    0
    anissov created

    Hi @ismcagdas, the link you have mentioned is broken!

  • User Avatar
    0
    ismcagdas created
    Support Team

    Hi @anissov

    You must be logged into GitHub by your allowed GitHub username (ahmad-moussawi) to see this link. It is a private link.

  • User Avatar
    0
    inforica created

    Hi @ismcagdas - I am having the same issue as described by @smastro.

    I am not able to see the link to the issue you have mentioned, What credentials ( userid/pwd) do I need to use for GitBub to view the same.

    Thanks, Sesha

  • User Avatar
    0
    ismcagdas created
    Support Team

    @inforica

    Yes, you have to be logged in to Github. Go to https://aspnetzero.com/LicenseManagement and add your GitHub user on "GitHub Members" tab.

  • User Avatar
    0
    chintanshah created
    "ClaimsMapping": [
            {
              "claim": "unique_name",
              "key": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
            }
          ]
    

    Adding above to appsettings.json (Inside OpenId) solved the <span class="colour" style="color: rgb(51, 51, 51);">[Problem #2]</span>