[Bug] [M] MSAL.NET fails if B2C user flows/policies have a name containing a dot (.)

[endintiers]

Which Version of MSAL are you using ?
MSAL 4.27

Platform
Xamarin/UWP

What authentication flow has the issue?
Other? - please describe;
AcquireTokenSilent/Identity Token Cache

Is this a new or existing app?
c. This is a new app or experiment

Repro
Create a B2C flow called {a}.signupsignin
AcquireTokenInteractive using that flow - works.
... later ...
GetAccountsAsync, which returns a valid Account
call IPublicClientApplication.AcquireTokenSilent with that account

Expected behavior
A user token is acquired from the token cache for the account.

Actual behavior
throws Microsoft.Identity.Client.MsalClientException: 'Returned user identifier does not match the sent user identifier when saving the token to the cache. '

Possible Solution
I assume the problem is the extra '.' in the homeAccountId.Identifier which looks like: {uid}-{a}.signupsignin.{tenantId}

I notice that in various places in the library, for example AccountId.ParseFromString, there is code such as
string[] elements = str.Split('.');
And then an assumption that there will only be 2 elements...

Rather than changing the split character (in many places) - which would probably cause other problems, or trying to deal with an array of length 'n', I would suggest:

1. Documenting: "Don't use '.' in your B2C flow/Policy names"
2. Checking for extra '.'s in homeAccountId.Identifiers when first seeing an Account - probably only needed in 3(ish) places? and throwing an exception (referencing the documentation).

[endintiers]

An alternative could be to unseal "Account".
In which case: string userIdentifier = ((Microsoft.Identity.Client.Account)account).HomeAccountId.Identifier.
would work, so no need to split the string?
(assuming we check that the IAccount is an Account first of course)

[bgavrilMS]

Looks more like a bug to me @jmprieur

[bgavrilMS]

See if we can use better parsing on AccountId. Otherwise, we can disallow dots.

[jmprieur]

@bgavrilMS : did we decide to close issues instead of adding the "Fixed" label?

[bgavrilMS]

Yes, I did not hear any objections.