Authentication process with external provider (Entra ID)

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Maybe this request is related somehow with issue #12217.

Scenario 1:

1. You have an application using Azure AD or Entra ID authentication context.Services.AddAuthentication().AddOpenIdConnect(...)
2. At first you only have the admin user.
3. A new user want to access using Azure Entra ID authentication.
4. The user is authenticated as expected and the application ask the user to fill the login and email before accessing the application.
5. Once the user fills the username and email he/she can access the application

Scenario 2:

1. You have an application using Azure AD or Entra ID authentication context.Services.AddAuthentication().AddOpenIdConnect(...)
2. At first you only have the admin user, sign in with admin and creates a new user with the required data: username, password and email (name.surname@yourcompany.com) without any block.
3. Now the user name.surname@yourcompany.com want to access the application with Azure Entra ID.
4. The user is authenticated as expected and the application ask the user to fill the login and email before accessing the application.
5. The user fills the data using the email name.surname@yourcompany.com
6. The application raise an alert saying that the user already exists
7. The user cannot sign in into the application unless he/she uses a different username and email address (which is not related to his/her company).

Describe the solution you'd like

I would like the login/registration process to be more simple for the end user.

In the scenario 1, steps 4 and 5 could be skipped if the application uses the external provider info to create the login (I guess this is what is happening in those steps) and let the user access to the application directly.

In the scenario 2, steps from 6 to 9 could be skipped as well. If the application knows that the login already exists, it could add the new authentication method for this user and let the user access to the application directly.

Additional context

Screen after success authentication with an external provider:

Screen after after success authentication with an external provider when the email already exist in the application:

Start by tracing the external-provider login and registration flow used by AddOpenIdConnect, including the path shown in the issue when a new user or an existing email is encountered. The work is done when both described scenarios can authenticate without unnecessary form entry or duplicate-user failure, with coverage for the changed flows.