我们有一个辅助AAD，来自主要AAD的猜测用户。为访客用户生成的令牌似乎缺少upn声明，但我们依赖于upn声明存在的事实，因为我们正在使用它来跨系统映射用户。
据我所知，对于已猜测的Microsoft Live帐户，可能缺少upn，但这些是完整的AAD帐户，只是在另一个AAD中。微软的文档还表明unique_name声明可能实际上并不是唯一的!!
https://docs.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中都会有不同的值。
答案 0 :(得分：3)
代表来自Azure AD的访客用户的令牌（以及代表ver==1.0的代币）确实会遗漏upn声明，但会包含unique_name声明，如您所发现的那样。这同样适用于来自其他Azure AD租户的来宾用户以及来自外部身份提供商的来宾用户。
来自其他Azure AD租户的来宾用户的unique_name声明的值将是用户的UPN（如果可用），或者以其他方式回退到用户的电子邮件地址。对于其他类型的访客用户，unique_name将采用其他格式＆amp;值。我们的想法是unique_name是访客用户最努力的人类可读标识符。
在任何情况下，都可以更改unique_name值，在极少数情况下，可能会发生冲突。这就是文档建议不要将其用作主要用户标识符的原因。 Azure AD系统中推荐的用户标识符是对象ID，或oid。
是的，不同租户的同一个人的oid会有所不同。但这就是Azure AD租赁模式的重点。另一个租户中的访客用户意味着作为与其“家庭”租户中的用户完全不同的用户。如果您想将这两个用户映射在一起，那么您可以做的最好就是使用启发式方法，例如unique_name。
我建议您在feedback.azure.com上提交一些请求：