我们有一个辅助 AAD，其中包含来自主 AAD 的来宾用户。 为来宾用户生成的令牌似乎缺少 upn 声明，但我们依赖于 upn 声明存在的事实，因为这是我们用来跨系统映射用户的令牌。
我知道访客Microsoft实时帐户可能缺少 upn，但这些是完整的 AAD 帐户，只是在另一个 AAD 中。Microsoft的文件还表明，unique_name声明实际上可能并不是唯一的！！
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-token-and-claims
你能告诉我是什么决定了unique_name索赔的价值吗？
如果 upn 声明不存在或是外部来宾用户，我们使用此声明回退是否安全？
来宾用户令牌内容
{
..,...
"tid": "xxxxxxxx-7ea7-413c-96bc-3f3aba133732",
"unique_name": "testAdmin@xxxxxxxx.onmicrosoft.com",
"ver": "1.0"
}
普通用户令牌内容：
{
......
"tid": "xxxxxxxx-72d8-4715-b14f-990c93843416",
"unique_name": "testAdmin@xxxxxxx.onmicrosoft.com",
"upn": "testAdmin@xxxxxxx.onmicrosoft.com",
"ver": "1.0"
}
我知道您可能希望我们使用"oid"，但这会导致我们在环境之间出现问题，因为同一用户在每个 AAD 中将是不同的值。
表示 Azure AD 中来宾用户的令牌(即ver==1.0中的令牌(确实会缺少upn声明，但会包含unique_name声明，正如你所发现的。 这等效地适用于来自其他 Azure AD 租户的来宾用户，以及来自外部标识提供者的来宾用户。
来自其他 Azure AD 租户的来宾用户的unique_name声明的值将是用户的 UPN(如果可用(，或者回退到用户的电子邮件地址。 对于其他类型的来宾用户，unique_name将采用其他格式和值。 这个想法是，unique_name是来宾用户尽力而为的人类可读标识符。
在任何情况下，都可以更改unique_name值，在极少数情况下，可能会发生冲突。 这就是文档建议不要将其用作主要用户标识符的原因。 Azure AD 系统中建议的用户标识符是对象 ID 或oid。
是的，对于不同租户中的同一个人，oid会有所不同。 但这就是 Azure AD 租户模型的重点。另一个租户中的来宾用户在应用程序中显示为与其"主"租户中的用户完全不同的用户。 如果要将这两个用户映射在一起，最好的办法就是使用启发式方法，例如unique_name。
我建议您在 feedback.azure.com 上提交以下几件事的请求：
- 可以跨租户标识用户的可靠用户标识符。
- 有关如何在 AAD 中处理来宾帐户的更好文档。