Still seeing same behavior. I worked around the phone number missing the space in a convoluted way with a series of claims transformations that put the "space" back in between the countryCode and number because I thought that would fix it. Unfortunately, It looks like the strongAuthenticationPhoneNumber
is saved off to the authentication methods in some weird "half-baked" state where its not enabled for signin, even with the space.
After the claim persists, it shows up in the user's Auth Methods page but with a blue box that says "This phone number can be used as a username to sign in. A text message will be sent for verification during sign-in." with a little "Enable" link. If you try to call the Graph API to retrieve the user's auth methods, it does not show up in the results.
However, if you click the "Enable" link in the UI, the blue box goes away and then the phone factor starts showing up in the API and all API methods work with it.
If you start in the UI and just enter a net-new phone number, you are forced to add a space between the country code and the national number via UI validation, and there is never a blue box, and it will show up in the API immediately like so:
{
"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users('#REDACTED#')/authentication/phoneMethods",
"value": [
{
"id": "3179e48a-750b-4051-897c-87b9720928f7",
"phoneNumber": "#REDACTED#",
"phoneType": "mobile",
"smsSignInState": "notAllowedByPolicy"
}
]
}
As of right now I have no workaround for how to obtain the users strongAuthenticationPhoneNumber
via the API after being set via a custom policy.