I have a bizarre issue happening. We have two levels of user managed in our Entra Customer (preview) tenant using Microsoft Entra External Id (in preview). Advisor and Client.

Advisors are only added through direct invitation and granted the Advisor group in the tenant. Advisor accounts are created in an older Azure AD workforce tenant (our corporate accounts).

Clients are able to register through our User Flow for the application and are added to a Client group.

Our application is a .net 8.0 blazor interactive mode application using Microsoft.Idenity with a DownstreamApi.

Advisors can hit our site, be redirected to the Entra User Flow to sign in, and then are brought back to our application with claims.

Clients hit the site, go to authenticate, and then an error is thrown when they are returned to /sign-in/oidc. My test client account was created through the user flow using a gmail account (but not using google oauth, just the email).

The error in my logs:

Message contains error: ‘invalid_request’, error_description: ‘AADSTS500208: The domain is not a valid login domain for the account type. Trace ID: <> Correlation ID: <> Timestamp: 2024-05-24 14:54:37Z’, error_uri: ‘error_uri is null’.

The AzureAD section for my application, which works fine for advisors in out Test environment in Azure, is as follows:

"AzureAd": {
  "Instance": "https://login.microsoftonline.com/",
  "TenantId": "33...33",
  "ClientId": "77...77",
    
  "EnablePiiLogging": false, // set to true to enable PII


  // If the app calls downstream APIs
  "ClientCredentials": [
    
    {
      "SourceType": "ClientSecret",
      "ClientSecret": "<<omitted>>"
    }
  ],
  "SendX5C": false,

  "AllowWebApiToBeAuthorizedByACL": false,

  // If the app is a web app:
  "ResetPasswordPath": "/MicrosoftIdentity/Account/ResetPassword",
  "ErrorPath": "/MicrosoftIdentity/Account/Error",
  "WithSpaAuthCode": false,

  "Scopes": [ "User.ReadBasic.All", "user.read", "email" ]
},

// Downstream APIs
"DownstreamApis": [
  {
    "ClaimsProvider": {
      "BaseUrl": "https://my-api.azurewebsites.net/api",
      "Scopes": [ "api://my-api.azurewebsites.net/88...88/ClaimsProvider.Read" ]
    }
  }
]

I thought perhaps there was bleed-through on my corporate account, so I ran my test in an incognito browser instance and what appears to happen is after I log in and it sends me to my application at /sign-in/oidc, if I retry accessing the root url it sends me back to the user flow again as if my first login was never done/persisted. This is in the same incognito window without closing. There is no error in the userflow when I login, only after I land back in the application on the default redirect page, which works just fine for advisor accounts.

The account in Entra created when I register through the user flow:

User type: Member
Creation Type: Local account
Identities: [email protected]

And the advisor Accounts who got the invitation and work look like this:

User type: Member
Creation Type: Invitation
Identities: ExternalAzureAd

We also have this issue with any local developers who are not in the Global Admin group. They have 2 Azure accounts attached to VS (one for corporate, one for the customer tenant), but when they try to access the app with the above configuration, they get the same error. Changing the AzureAd config locally to the below fixes it for their Advisor account but does not fix the Client account when the same config is deployed into Azure

"AzureAd": {
  "Authority": "https://33...33.ciamlogin.com/33...33/v2.0",
  "Instance": "https://33...33.ciamlogin.com/33...33/v2.0",
  "Domain": "myTenant.onmicrosoft.com",
  "ClientId": "77...77",

  //... rest of config the same
}

The App service is hosted on our corporate tenant subscription in Azure and configured to use the Entra Customer tenant for authentication. The app service in Test is configured as:

App Service authentication: Enabled
Restrict access: Allow unauthenticated requests
Token store: Enabled

My Identity Provider is configured as:

Identity provider: Microsoft
App registration: Unable to resolve app registration name from registered application ID
Supported account types: Unable to resolve account type information from registered application ID
Application (client) ID: bb…bb
Client secret value: Click to edit secret value
Issuer URL: https://myTenant.ciamlogin.com
Allowed token audiences: [blank]
Client application requirement: Allow requests only from this application itself
Identity requirement: Allow requests from any identity
Tenant requirement: Allow requests from specific tenants
Allowed tenants: 33…33