I am running into the issue described in this docbug:
https://github.com/MicrosoftDocs/azure-docs/issues/26573
It seems that if the value of a user's country attribute is anything other than a two-character string, that value is rejected and ANY user claims that refer to user.country, including...
- the OIDC ctry claim
- any custom claims that directly refer to user.country
- Any custom claim that has a transformation that includes user.country as one of the values
...will not have a value for the country passed in the JWT token.
According to https://video2.skills-academy.com/en-us/entra/identity-platform/optional-claims-reference#v10-and-v20-optional-claims-set, the rules for the optional ctry claim are as follows:
ctry |
User's country/region |
JWT |
|
This claim is returned if it's present and the value of the field is a standard two-letter country/region code, such as FR, JP, SZ, and so on. |
|
|
|
|
|
This seems like a bug. It appears that whatever code within Entra ID is performing the validation on populating the ctry attribute is doing the validation early, once it picks up the value of user.country from Entra ID. Instead, it seems as if the validation should be done later at the time the ctry claim is dropped into the JWT token. In that case, any non-two-character code would be rejected for the ctry claim, but wherever user.country is used for custom claims (transformed or not), the value would get passed to the JWT token.
Here's where it's impacting us (and I'm assuming other organizations). Microsoft 365 expects the user.country attribute to be the spelled-out name of the country, not the two-character ISO abbreviation. See https://video2.skills-academy.com/en-us/microsoft-365/enterprise/configure-user-account-properties-with-microsoft-365-powershell?view=o365-worldwide as an example of where Microsoft has documented this. As such, our users have that attribute populated with values such as "Canada" and "Germany", rather than "CA" and "DE". Any custom claims that use user.country are effectively NULL. Please "shift right" on the validation logic. Thanks.