SID from ZUMO Login (MobileServiceUser) differs from the users' ObjectId - xamarin.forms

Question

I am working on a Xamarin.Forms based crossplatform app targetting iOS and Android. My backend is an ASP.NET Webapplication hosted as an Azure App Service and users can register accounts that I manage with Azure Active Directory B2C. For authentication, I use MSAL 4.0 and the client application communicates with the backend using the MobileServiceClient library.
Because the users' data has relationships, I chose to let the controllers' put methods add the users' SIDs automatically and filter requested data on that SID, because this identifier is available after authorization though the users IClaimsPrincipal anyway.
However, I don't understand the origins of these SIDs because I cannot find them anywhere else.
This is what I can tell so far:
Within Azure ADB2C, I have two registered users. One of them (UserA) came in using Facebook as IdentityProvider, the other (UserB) Microsoft.
UserA has the Object Id FFC1*** on ADB2C.
UserB has the Object Id E990*** on ADB2C.
Both have the same name, but different registered email addresses.
This is how I instantiate the MSAL client:
public static IPublicClientApplication PCA = null;
...
PCA = PublicClientApplicationBuilder.Create(ClientID)
.WithRedirectUri($"msal{ClientID}://auth")
.WithB2CAuthority(Authority)
.WithIosKeychainSecurityGroup("com.microsoft.msalrocks")
.Build();
ClientId refers to Azure Active Directory B2C > Applications > Application > Application Id
Authority resolves to something like https://application.b2clogin.com/tfp/application.onmicrosoft.com/B2C_1_SignInSignUp
The policy configuration (user flow) on B2C is configured to include the following claims:
Given Name
Identity Provider
User's Object Id
I log in using MSAL this way:
var accounts = await App.PCA.GetAccountsAsync();
var result = await App.PCA.AcquireTokenSilent(
App.Scopes,
accounts.FirstOrDefault())
.WithB2CAuthority(App.Authority)
.ExecuteAsync();
App.Scopes resolves to
public static string[] Scopes = {
"https://application.onmicrosoft.com/api/user_impersonation",
"https://application.onmicrosoft.com/api/offline_access"};
At this point, I have an AuthenticationResult which I could extract valuable information from such as the users' given name or the Object Id which equals the Object Id I can also see in the user management pane in my Azure B2C directory:
JObject authenticatedUser = AuthenticationHelper.ParseIdToken(result.IdToken);
var objectId = authenticatedUser["sub"]?.ToString();
var username = authenticatedUser["given_name"]?.ToString();
The AuthenticationResult contains an IdToken and an AccessToken. They are almost identical with the AccessToken adding an scp attribute containing scopes. In my case it contains "user_impersonation".
Now with the user being authenticated against ADB2C, I need my app to also forward the authentication to ZUMO, that is, the MobileServiceClient, so that the user can make authorized calls against my backends' controllers.
For this, I need the resturned AccessToken (which I can also extract from the above AuthenticationResult), wrap it into a JObject and finally transmit it to the MobileServiceClient like this:
MobileServiceClient client;
client = new MobileServiceClient("https://application.azurewebsites.net");
var zumoPayload = new JObject()
{
["access_token"] = result.AccessToken
};
await client.LoginAsync(MobileServiceAuthenticationProvider.WindowsAzureActiveDirectory, zumoPayload);
Now that the MobileServiceClient has an authenticated user, every future httprequest will contain respective information that the controllers' [authorize] attribute satisfy.
HOWEVER.
This is when it becomes strange.
When the MobileServiceClient is instantiated and its LoginAsync method called using the ZumoPayload from above, the resulting MobileServiceUser is being populated with two properties:
MobileServiceAuthenticationToken and
UserId
The funny thing is, that this token looks very different from the IdToken or AccessToken I received when authenticating with MSAL, but what bugs me even more is that the User Id is even something totally different!
There is a sub attribute included containing something like sid:956b*** for UserA and sid:e358*** for UserB which clearly differ from the above Object Ids.
Can anyone explain to me where these SIDs come from?