Can we pass an email and password to azure ad b2c via next-auth?

Question

We have a custom sign in page where users enter their email and password. We are trying to pass this to azure ad b2c via the next-auth signIn function but it is just displaying an azure sign in page instead of authenticating the user with the entered values. Our sign in code looks like this

const result = await signIn("azure-ad-b2c", {
    email: email,
    password: password,
    redirect: true,
  });

and the next-auth provider looks like this

 providers: [
    AzureADB2CProvider( {
      tenantId: process.env.AD_B2C_Client_Tenant_Name,
      clientId: process.env.AD_B2C_Client_AppId, // AZURE_Client_AppId
      clientSecret: process.env.AD_B2C_Client_Client_Secret,
      primaryUserFlow: process.env.AD_B2C_Client_PrimaryUserFlow_SignIn,
      authorization: { params: { scope: "offline_access openid" } },
    }),
]

So the first question - is this even possible?

we configured the application in azure and configured the next-auth provider. We were expecting azure to authenticate the user using the passed email and password and to return an object to the callback url (http://localhost:4000/api/auth/callback/azure-ad-b2c) .

Answer 1

Typically this is considered extremely bad practice. The reason for implementing a service like Azure AD B2C is that you hand off the authentication experience and mitigate against the risks where your app needs to handle users' passwords.

If you want to sign-in a user by passing their email/password to the Azure AD B2C service, you would need to implement a ROPC (Resource Owner Password Credentials) policy. You can do this with the out-of-the-box user flows or custom policies by following this documentation: Set up a resource owner password credentials flow in Azure Active Directory B2C.

In most scenarios, more secure alternatives are available and recommended. This flow requires a very high degree of trust in the application, and carries risks that are not present in other flows. You should only use this flow when other more secure flows aren't viable

When using the ROPC flow, consider the following:

• ROPC doesn’t work when there's any interruption to the authentication flow that needs user interaction. For example, when a password has expired or needs to be changed, multifactor authentication is required, or when more information needs to be collected during sign-in (for example, user consent).
• ROPC supports local accounts only. Users can’t sign in with federated identity providers like Microsoft, Google+, Twitter, AD-FS, or Facebook.
• Session Management, including keep me signed-in (KMSI), isn't applicable.

Note, ROPC will not be supported in the next version of the OAuth specification.