1

is it possible to achieve the aimed scenario?

<!DOCTYPE html>
<html>
<head>
    <title>My Product Brand Name</title>
</head>
<body>
    <!-- api.localaccountsignup section -->
    <div id="api1"></div>
    <!-- api.signuporsignin -->
    <div id="api2"></div>
</body>
</html>

Ideally, I'd have a frontend that hosts local account signup and signup or signing, as the image below

image

basquiatraphaeu
  • 525
  • 7
  • 19

1 Answers1

2

Create 2 policies.

  1. A Sign Up policy. It will use B2C to render the "Full Name", "Email" and "Password" fields. Use custom HTML to add 3 buttons "Google", "Facebook", "LinkedIn". Each button will link to your application: myapp.com/<social_provider_name>. When a user hits one of these links, the app should send the user to the 2nd policy with a respecticve domain_hint parameter.

  2. This policy will have "Google", "Facebook", "LinkedIn" IdPs configured. Each will be configured for direct sign in. The app will pass a parameter domain_hint based off of the users action from Policy 1, and will then cause the user to hit the Social IdP they selected.

Adding parameters using MSAL: https://learn.microsoft.com/en-us/azure/active-directory-b2c/enable-authentication-spa-app-options#pass-a-custom-query-string-parameter

Jas Suri - MSFT
  • 10,605
  • 2
  • 10
  • 20
  • Please correct me if I am wrong, as I'm working on top of [auto-account-linking sample](https://github.com/azure-ad-b2c/samples/tree/master/policies/auto-account-linking) I already have the "first policy" you've mentioned represented by the technical profile "LocalAccountSignUpWithLogonEmail-HasEmailFlagged" and a custom HTML attached to the content definition "api. localaccountsignup". How does the second policy should look like considering that I already have the required IdPs setup on AccountLinkSignUpOrSignin.xml? Do I really need a second policy? – basquiatraphaeu Dec 15 '21 at 13:56
  • Also, where can I find myapp.com/ or is it just a mock uri? – basquiatraphaeu Dec 15 '21 at 14:16
  • `myapp.com/` is your app. You need to implement logic at an endpoint like that. Or however you want the endpoint to look like at your app so your app understands how to execute authentication with MSAL for policy2. If you are using account linking sample already, then you dont need policy2. Just add the buttons and links like i mentioned, and send the user to policy1 (it already handles `domain_hint`). – Jas Suri - MSFT Dec 16 '21 at 10:19
  • thanks for all the info. I was able to achieve the expected scenario. My current concern, however, is with the extra configuration and files that need to be maintained now. I wonder if these self-asserted fields and the 3 idps buttons couldn't be achieved using only custom policies. Something similar to the layout we have for signin or signup scenarios. e.g. (username and password input fields + idps buttons) – basquiatraphaeu Dec 17 '21 at 15:00
  • 1
    It can’t be done in any other way. You can’t put social IdP buttons on anything but the combined sign in and sign up” page. – Jas Suri - MSFT Dec 18 '21 at 00:45
  • I see. Would be possible to reuse the combined sign-in/up again. Something close to what I´m trying here: https://stackoverflow.com/questions/70428808/azure-ad-b2c-invoke-a-subjouney-whenever-a-user-clicks-to-sign-up – basquiatraphaeu Dec 21 '21 at 15:10