如何配置Azure AD B2C实现预创建用户受邀设置初始密码

全程使用内置用户流实现，不需要编写自定义策略，维护成本与原生内置功能一致。 #

核心思路 #

放弃Azure AD自带的「临时密码+强制改密」默认邀请流程，以内置密码重置流为承载，通过全量替换UI文案把「重置密码」的用户感知改成「首次设置初始密码」，配合Graph API预创建用户、业务侧自定义发信，完全对齐原有邀请流程的体验，同时通过多层权限配置锁死用户自助修改邮箱的入口。 #

具体配置步骤 #

1. 基础租户配置 #

• 身份提供者仅启用「本地账户（邮箱）」，关闭所有外部身份提供者（微软个人账号、Google等）的注册/登录入口，从根源堵死用户用个人邮箱自助注册的路径。
• 新建2个内置用户流，均选择官方推荐的最新稳定版本：
  • 登录流：基于「登录」模板创建，完全关闭流内的自助注册入口，仅保留邮箱+密码登录功能
  • 初始密码设置流：基于「密码重置」模板创建，验证方式仅勾选「邮箱验证码」，关闭所有需要验证旧密码的选项

2. 预创建用户的Graph API参数配置 #

通过Microsoft Graph API提前录入授权用户时，按以下参数配置即可，不需要给用户发送临时密码：

{
  "accountEnabled": true,
  "displayName": "录入的用户姓名",
  "mailNickname": "用户邮箱前缀",
  "identities": [
    {
      "signInType": "emailAddress",
      "issuer": "你的B2C租户默认域名，格式类似<你的租户名>.onmicrosoft.com",
      "issuerAssignedId": "管理员审核通过的用户工作邮箱"
    }
  ],
  "passwordProfile": {
    "forceChangePasswordNextSignIn": true,
    "password": "生成一个16位以上符合复杂度要求的随机字符串作为占位值，该值永远不告知用户"
  }
}

注意：这里的占位密码仅做系统侧字段补全用，用户全程不会接触到这个值，不会出现「拿临时密码登录」的步骤。

3. 定制初始密码设置流的用户感知 #

进入刚创建的密码重置用户流的语言配置页，为服务覆盖的用户语言开启自定义文案，把所有和「重置密码」相关的表述全部替换为首次设置密码的内容：

• 流程页标题统一改为「设置初始登录密码」
• 邮箱输入页提示文案改为「请输入您的授权工作邮箱，我们将发送验证码至该邮箱，验证通过后即可设置登录密码」
• 验证码输入页提示文案改为「请输入发送至您工作邮箱的6位验证码」
• 密码输入页提示文案改为「请设置您的初始登录密码，密码需满足长度≥8位，同时包含大小写字母、数字与特殊符号」
  替换完成后，用户走这个流程的视觉感知和原有自研系统的邀请设密流程完全一致，不会出现「我从来没设过密码为什么要重置」的困惑。

4. 对接原有邀请发信逻辑 #

不要使用Azure AD B2C自带的邀请邮件（该邮件文案不可全量定制，会出现重置密码相关表述），直接复用原有业务系统的邀请邮件模板：

• 邀请链接拼接初始密码设置流的授权端点，带上业务侧的邀请校验令牌、预填用户邮箱参数、业务系统重定向地址，示例格式：

https://<你的B2C租户名>.b2clogin.com/<你的B2C租户名>.onmicrosoft.com/oauth2/v2.0/authorize?p=B2C_1_<你创建的初始密码设置流名>&client_id=<你的业务应用客户端ID>&nonce=随机生成的nonce值&redirect_uri=<你在B2C中备案的业务系统重定向地址>&scope=openid offline_access&response_type=code id_token&prompt=login&login_hint=<预填的用户工作邮箱>&state=<你的业务系统邀请令牌，用于校验邀请合法性>

• 用户点击链接后，会直接进入定制好文案的设密流程：邮箱已预填、收取验证码、设置密码，完成后直接跳转回业务系统，全程无突兀的平台默认提示。

5. 锁死用户邮箱修改权限，确保仅管理员可管控登录邮箱 #

• 不要给普通用户开放内置的「编辑个人资料」用户流入口，普通用户登录后无自助修改个人标识（登录邮箱）的入口。
• 给组织内的特权用户分配的Graph API权限做最小化裁剪：仅授予其创建本组织用户的权限，不授予更新任意用户identities属性的权限，避免特权用户越权修改邮箱。
• 业务系统后端做兜底校验：每次收到B2C返回的登录令牌后，提取令牌中的邮箱声明，校验两个规则：① 该邮箱属于用户所属付费组织备案的工作邮箱域；② 邮箱后缀不属于Hotmail、Outlook.com、gmail.com等公共个人邮箱域，校验不通过直接拒绝登录。
• 配置B2C条件访问策略，拦截所有普通用户自助修改身份标识的请求，所有邮箱变更操作必须走业务系统的管理员后台，由管理员审核后调用Graph API完成更新。

方案适配性验证 #

• 全程使用官方内置用户流，没有自定义策略相关的开发、维护成本，后续微软更新内置流的安全补丁、功能迭代会自动生效，不存在自定义策略的生命周期维护问题
• 用户侧流程和原有自研邀请设密流程完全对齐，没有「重置密码」的误导性表述
• 多层权限+兜底校验确保用户无法自行修改登录邮箱，也无法用个人邮箱登录，完全符合管理员管控要求

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