Parsed and Prompted Home Realm Discovery?

[azure-ad-b2c]

Parsed and Prompted Home Realm Discovery?

[JasSuri]

You can combine these two samples:
HRD via Domain_Hint
HRD by collecting and parsing an email domain

Where a domain_hint is not passed, you can be sent to the default Idp, which Sample 1 does already, just swap the claimsExcahnge from the AAD OIDC technical profile to the LocalAccountSignIn technical profile reference Id.
Then use Sample 2 to see how to parse the domain from the email entry presented at the LocalAccountSignIn technical profile.

[alex-mason-by]

I wonder if I might share my policy to see what am doing wrong as I feel like the logic I have is almost there? I have a parsed domain hint exchange followed by a prompted domain hint exchange preconditioned by the output of the first exchange. I have seen a couple different outcomes neither of which works exactly. One of the outcomes seems to end in some sort of infinite loop. My goal is to use the same matching lookup in both from a known list of domains.

[alex-mason-by]

So, I closed this issue earlier since I did successfully implement parsed and then prompted HRD. It seems to work fine for interactive logins. I now am wrestling with silent token flow and MSAL.js in particular. @JasSuri When you consider these HRD schemes based on domain_hint etc. do you not think it is necessary to pass both login_hint and domain_hint in order to navigate the orchestration steps? I seem to be able to get silent access token call working only when I intercept a failing silent call and append both domain_hint and login_hint. I am specifically testing the behavior with my policy and this MSAL.js PR changes - AzureAD/microsoft-authentication-library-for-js#1299

[JasSuri]

I'll look into this and confirm.

[JasSuri]

Closing this issue, as it was determined there was an orchestration step without any session management. There is no need to pass login_hint or domain_hint in this sample for silent token calls.