Azure AD B2C应用开发中，开发者使用Office 365的最佳实践咨询

为啥B2C目录没法分配Office 365许可证？ #

首先得明确：Azure AD B2C是专门为消费者身份管理设计的目录，它的架构和标准Azure AD完全不同，天生就不支持Office 365这类企业生产力套件的许可证分配——哪怕你关联了自定义域名foobar.net也没用，因为目录类型的限制摆在这儿。

更优方案：用标准Azure AD+B2B协作搞定单账号访问 #

这是比让开发者用两个账号更顺畅的解决办法，步骤很清晰：

• 先创建一个标准Azure AD目录（别选B2C类型），这个目录专门用来管理Office 365许可证和你的内部开发者/管理员账号
• 在这个标准目录里给开发者分配Office 365许可证，他们用这个目录的账号（比如dev@foobardev.onmicrosoft.com或者绑定自定义域名后的dev@foobar.net）就能正常使用Office 365
• 把标准Azure AD里的开发者账号邀请为B2C目录的B2B协作用户，然后在B2C目录里给他们分配对应的管理角色（比如B2C Identity Experience Framework管理员、应用管理员等）

这样一来，开发者只需要一个账号，就能同时访问Office 365资源和管理B2C应用的所有配置，完全不用切换两个账号，体验顺畅很多。而且B2B协作用户在B2C目录里拥有完整的管理权限，完全能满足开发和运维需求。

如果一定要新建目录，命名怎么选？ #

如果因为某些场景限制，你还是倾向于新建独立的标准Azure AD目录来管理Office 365，命名上建议贴合业务用途，方便团队识别：

• 你提到的foobardev.onmicrosoft.com就非常合适，直接点明是foobar项目的开发管理目录
• 也可以考虑foobaradmin.onmicrosoft.com（突出管理属性）、foobarcorp.onmicrosoft.com（强调企业内部管理）这类命名
• 尽量避免太模糊的名字，比如dev.onmicrosoft.com或者test.onmicrosoft.com，时间长了容易搞混不同项目的目录

总结 #

优先推荐标准Azure AD+B2B协作的方案，既解决了许可证分配的核心问题，又实现了单账号统一访问，是目前最合理的选择。如果必须新建目录，记得用清晰关联业务的命名规则。

内容的提问来源于stack exchange，提问作者kemakino