在环境中部署和作防钓鱼无密码身份验证时，我们建议采用基于用户角色的方法，但这可能因你所在的行业和可能拥有的预算等其他方面而异。 此部署指南可帮助你查看组织中用户对哪种类型的方法和推出计划有意义。 抗钓鱼的无密码部署方法包含多个步骤，但在继续进行其他步骤之前不需要完全完成每一步。
确定用户角色
确定与组织相关的用户角色。 此步骤对项目至关重要，因为不同的角色具有不同的需求。 Microsoft建议你考虑并评估组织中的以下用户角色。
| 用户角色 | 说明 |
|---|---|
| 管理员和高度管控的用户 | |
| 非管理员 |
Microsoft 建议在整个组织内广泛部署防网络钓鱼无密码身份验证。 建议首先使用用户角色之一开始部署。
Microsoft建议根据这些角色对用户进行分类，然后将用户放入专门为该用户角色设置的 Microsoft Entra ID 组。 这些组将在以后的步骤中使用，以便向不同类型的用户推出凭据，并在开始强制使用防网络钓鱼无密码凭据时使用。
通过使用团队，你可以继续同时引入组织的新部分。 采取“勿以善小而不为”的方法，尽可能多地部署安全凭据。 随着越来越多的用户使用防网络钓鱼的无密码凭据登录，就会减少环境的攻击面。
规划设备就绪状态
设备是任何成功的防钓鱼无密码部署的一个重要方面。 若要确保设备已准备好抵御网络钓鱼的无密码认证，请将每个操作系统更新到所支持的最新版本。 若要使用防钓鱼凭据，设备必须至少运行这些版本：
- Windows 10 22H2（适用于 Windows Hello 企业版）
- Windows 11 22H2（使用通行密钥时获得最佳用户体验）
- macOS 13 Ventura
- iOS 17
- Android 14
这些版本原生与 passkey、Windows Hello 企业版和 macOS 平台凭据等功能集成。 较旧的操作系统可能需要 FIDO2 安全密钥等外部验证器来支持防网络钓鱼无密码身份验证。
有关更多详细信息，请熟悉 Microsoft Entra ID 的 FIDO2 可支持性。 可以使用 防钓鱼无密码工作簿（预览版） 了解租户中的设备就绪情况。
抗网络钓鱼旅程
作为抗钓鱼凭据部署的一部分，你需要考虑如何为用户设置和管理，如何获取其便携和本地凭据，以及在整个组织中如何强制实施抗钓鱼凭据。
注册用户以获取防网络钓鱼凭据
凭据注册和引导是防网络钓鱼无密码部署项目中第一个面向最终用户的主要活动。 本部分介绍便携式凭据和本地凭据的推出。
在下表中，你将找到可在 Entra ID 中配置的不同类型的凭据和关联的身份验证方法。
| 凭据 | 说明 | 优点 | 身份验证方法 |
|---|---|---|---|
| 便携式 | 可跨设备使用。 可以使用便携式凭据登录到其他设备，或在其他设备上注册凭据。 | 对大多数用户来说，这是需要注册的最重要的凭据类型，因为它们可以跨设备使用，并在许多应用场景中提供防网络钓鱼身份验证。 | |
| 本地 | 可以使用 本地 凭据在设备上进行身份验证，而无需依赖外部硬件。 | 本地凭据提供出色的用户体验，因为用户无需离开设备即可使用设备自己的解锁手势（例如人脸 ID 或 Windows Hello 企业版人脸/指纹/PIN）成功进行身份验证。 |
- 对于没有现有企业凭据的新用户，注册和引导过程将会验证他们的身份。 其将用户引导到第一个便携式凭据，并使用该便携式凭据在每个计算设备上引导其他本地凭据。 注册后，管理员可在 Microsoft Entra ID 中为用户强制实施防钓鱼身份验证。
- 对于 现有用户，他们必须在现有设备上注册防钓鱼无密码，或使用现有的 MFA 凭据来启动防钓鱼的无密码凭据。
这两种类型的用户的最终目标是相同的 - 大多数用户应该至少有一个 可移植 凭据，然后在每个计算设备上拥有 本地 凭据。
注意
始终建议用户至少注册两种身份验证方法。 这可确保在用户的主要方法出现问题（例如设备丢失或被盗）时有备用方法可用。 例如，用户最好在其工作站上注册密钥和本地凭据（例如 Windows Hello 企业版）
步骤 1：身份验证
对于尚未证明其身份（例如新员工）的远程用户，企业载入是一项重大挑战。 如果没有适当的身份验证，组织无法完全确定他们打算载入的人员。 Microsoft Entra 验证 ID 可以提供高保障身份验证。 组织可与身份验证合作伙伴 (IDV) 协作，在载入过程中验证新远程用户的标识。 处理用户政府颁发的 ID 后，IDV 可以提供确认用户标识的已验证 ID。 新用户向招聘组织提供此标识确认的已验证 ID，以建立信任并确认组织正在载入正确的人员。 组织可以使用 Microsoft Entra 验证 ID 添加人脸检查，从而在验证中添加面部匹配层，确保受信任的用户在该时刻显示标识确认的已验证 ID。
通过校对过程验证身份后，新员工将获得一个临时访问通行证 (TAP)，他们可以用于启动其第一个可移植凭据。
请参阅以下指南以启用 Microsoft Entra 验证 ID 载入和 TAP 颁发：
有关 Microsoft Entra 验证 ID 的许可详细信息，请参阅以下链接：
有些组织可能会选择 Microsoft Entra 验证 ID 以外的其他方法来载入用户并颁发其第一个凭据。 Microsoft 建议这些组织仍然使用 TAP 或其他无需密码即可让用户登录的方法。 例如，可以使用 Microsoft Graph API 预配 FIDO2 安全密钥。
步骤 2：启动可移植凭据
要引导现有用户使用防网络钓鱼无密码凭据，请先确定用户是否已注册传统 MFA。 注册了传统 MFA 方法的用户可能会成为防网络钓鱼无密码注册策略的目标。 他们可以使用传统 MFA 注册第一个便携式防网络钓鱼凭据，然后再根据需要继续注册本地凭据。 最佳做法是使用 Microsoft Entra 验证 ID 集成，以便使用临时访问通行证（TAP）注册防钓鱼身份验证方法。
对于新用户或没有 MFA 的用户，请进行一个过程以向其发放 TAP。 发放 TAP 可以使用与为新用户提供其第一个凭据相同的方式，也可以使用 Microsoft Entra 验证 ID 集成。 用户拥有 TAP 后，即可引导其第一个防网络钓鱼凭据。
用户的第一个无密码凭据必须是可用于在其他计算设备上进行身份验证的便携式凭据，这一点很重要。 例如，通行密钥可用于在 iOS 手机上进行本地身份验证，但也可用于在 Windows PC 上使用跨设备身份验证流进行身份验证。 此跨设备功能允许在使用已加入 Microsoft Entra ID 并启用 Windows 的 Web 登录 的设备时，使用可移植密码钥匙在 Windows PC 上启动 Windows Hello for Business。
下表列出了适用于不同用户角色的建议可移植凭据：
| 用户角色 | 建议的便携式凭据 | 备用便携式凭据 |
|---|---|---|
| 管理员和高度管控的用户 | FIDO2 安全密钥 | 用于 Microsoft Authenticator 的密码键及用于基于证书验证（智能卡）的身份验证 |
| 任何其他用户 | 同步的密钥 | FIDO2 安全密钥，Microsoft Authenticator 应用的密码 |
密码身份验证凭据的范围可以限定为使用 passkey 配置文件的特定用户组。 应为每个用户角色设置一个通行密钥配置文件，并选择推荐的可移植凭据。
使用以下指导为组织的相关用户角色启用建议和替代的便携式凭据：
| 方法 | 指导 |
|---|---|
| FIDO2 安全密钥 | |
| 同步的密钥 | |
| Microsoft Authenticator 中的通行密钥 | |
| 智能卡和基于证书的身份验证 (CBA) |
步骤 3：启动本地凭据
建议用户定期使用的每个设备都具有本地可用的凭据，以便为用户提供尽可能流畅的用户体验。 本地可用的凭据减少了进行身份验证所需的时间，因为用户不需要使用多个设备，并且用户使用设备解锁手势进行身份验证。
用户获取其可移植凭据后，该凭据可用于引导其本地凭据，从而使用户能够在他们拥有的其他设备上原生使用防钓鱼凭据。
注意
共享设备的用户应仅使用可移植凭据。
使用下表确定每个用户角色首选哪种类型的本地凭据：
| 用户角色 | 建议的本地凭据 - Windows | 建议的本地凭据 - macOS | 建议的本地凭据 - iOS | 建议的本地凭据 - Android | 建议的本地凭据 - Linux |
|---|---|---|---|---|---|
| 管理员和高度管控的工作人员 | Windows Hello 企业版或 CBA | 平台 SSO 安全 Enclave 密钥或 CBA | Microsoft Authenticator 或 CBA 中的 Passkey | Microsoft Authenticator 或 CBA 中的 Passkey | 不适用（改用智能卡） |
| 非管理员 | Windows Hello 企业版 | 平台单一登录 (SSO) 安全 Enclave 密钥 | 同步的密钥 | 同步的密钥 | 不适用（改用便携式凭据） |
使用以下指导为组织的相关用户角色在环境中启用建议的本地凭据：
| 方法 | 指导 |
|---|---|
| Windows Hello 企业版 | |
| 适用于 macOS 的平台凭据 | |
| Microsoft Authenticator 中的通行密钥 |
角色特定的注意事项
在每个角色中，可能有特定的角色功能，这将有自己的挑战和注意事项。 您可以参考下表，其中包含组织中特定角色所需的指导。
| Persona | 示例角色 |
|---|---|
| 管理员 | |
| 非管理员 |
推动使用防网络钓鱼凭据
此步骤介绍如何让用户更轻松地采用防网络钓鱼凭据。 应测试部署策略、规划推出，并将计划传达给最终用户。 然后，可以在整个组织内强制实施防网络钓鱼凭据之前创建报告并监视进度。
测试部署策略
Microsoft 建议使用一组测试和试点用户测试在上一步中创建的部署策略。 此阶段应包括以下步骤：
- 创建测试用户和早期采用者的列表。 这些用户应代表不同的用户角色，而不仅仅是管理员，以及使用受支持的设备类型。
- 创建 Microsoft Entra ID 组，并将测试用户添加到该组。
- 在 Microsoft Entra ID 中启用身份验证方法策略，并将测试组的范围限定为所启用的方法。
- 使用身份验证方法活动报告衡量试点用户的注册推出。
- 创建条件访问策略，以在每个操作系统类型上强制使用防钓鱼无密码凭据，并针对试点组实施。
- 使用 Azure Monitor 和工作簿衡量强制实施是否成功。
- 收集用户对推出是否成功的反馈。
计划推出策略
Microsoft 建议哪些用户角色最适合部署来推动使用。 通常，这意味着先使用管理员进行试点，然后广泛部署到非管理员用户组，但这可能会根据组织的需求而更改。
使用以下部分为每个用户群体创建最终用户通信，定义范围并推出密钥注册功能，还可以通过用户报告和监控来跟踪推出进度。
使用 Phishing-Resistant 无密码工作簿推动准备就绪（预览版）
组织可以选择将其Microsoft Entra ID 登录日志导出到 Azure Monitor ，以便长期保留、威胁搜寻和其他目的。 Microsoft发布了一个 工作簿，供在 Azure Monitor 中保存日志的组织使用，以帮助进行抗网络钓鱼的无密码部署的各个阶段。 可在此处访问 Phishing-Resistant 无密码工作簿： aka.ms/PasswordlessWorkbook。 选择标题为 Phishing-Resistant 无密码部署（预览版） 的工作簿：
工作簿有两个主要部分：
- 注册就绪阶段
- 执行准备阶段
注册就绪阶段
使用“注册就绪阶段”选项卡分析租户中的登录日志，确定哪些用户已准备好注册，哪些用户可能被阻止注册。 例如，使用“注册就绪阶段”选项卡，可以选择 iOS 作为 OS 平台，然后在 Microsoft Authenticator 中传递密钥作为要评估准备情况的凭据类型。 然后，您可以单击工作簿的可视化组件，以缩小筛选范围至预计会有注册问题的用户，并导出该用户列表。
工作簿的“注册准备阶段”选项卡可帮助你评估以下操作系统和凭据的准备情况：
- Windows
- Windows Hello 企业版
- FIDO2 安全密钥
- Certificate-Based 身份验证/智能卡
- macOS
- 平台 SSO 安全 Enclave 密钥
- FIDO2 安全密钥
- Certificate-Based 身份验证/智能卡
- iOS
- 同步的密钥
- FIDO2 安全密钥
- Microsoft Authenticator 中的通行密钥
- Certificate-Based 身份验证/智能卡
- 安卓
- 同步的密钥
- FIDO2 安全密钥
- Microsoft Authenticator 中的通行密钥
- Certificate-Based 身份验证/智能卡
使用每个导出的列表对可能存在注册问题的用户进行会审。 对注册问题的响应应包括帮助用户升级设备 OS 版本、替换老化的设备，以及选择首选选项不可行的备用凭据。 例如，组织可以选择向无法使用同步密码的 Android 13 用户提供物理 FIDO2 安全密钥。
同样，使用注册准备报告来帮助你构建准备好开始注册通信和活动的用户列表，以符合总体实施策略。
执法准备阶段
一旦用户准备好进行仅抗网络钓鱼身份验证，您可以强制实施这种抗网络钓鱼验证，这意味着他们需要使用抗网络钓鱼凭据执行 MFA 才能根据您的策略访问资源。
强制就绪阶段的第一步是在 Report-Only 模式下创建条件访问策略。 这一策略会在你的登录日志中填入关于访问是否会被阻止的数据，前提是你将用户/设备纳入防网络钓鱼的强制执行范围。 使用以下设置在租户中创建新的条件访问策略：
| 设置 | 价值 |
|---|---|
| 用户/组分配 | 所有用户，不包括玻璃帐户 |
| 应用分配 | 所有资源 |
| 授权控制 | 需要身份验证强度 - 防钓鱼 MFA |
| 启用策略 | 仅限报告 |
在推广过程中尽早创建此策略，最好是在开始注册活动之前。 这将确保你拥有一个良好的历史数据集，显示如果策略被强制执行，哪些用户和登录会被阻止。
接下来，使用工作簿分析用户/设备对是否已准备好进行强制实施。 下载准备强制实施的用户列表，并将其添加到与 强制策略一致的组。 首先在策略筛选器中选择只读条件访问策略：
该报告将提供一个用户列表，这些用户能够在每个设备平台上成功通过支持防钓鱼的无密码要求。 下载每个列表，并将相应的用户置于与设备平台一致的强制组中。
随着时间的推移重复此过程，直到每个强制组包含大多数或全部用户为止。 最终，应该能够启用仅报告策略，为租户中的所有用户和设备平台提供强制。 达到此完成状态后，可以删除每个设备 OS 的单个强制策略，从而减少所需的条件访问策略数。
对未准备好接受强制执行的用户进行调查
使用“ 进一步数据分析 ”选项卡调查为什么某些用户尚未准备好在各种平台上强制执行。 选择 “策略不满意 ”框，将数据筛选为仅报告条件访问策略阻止的用户登录。
使用此报告提供的数据来确定哪些用户会被阻止、他们所在的设备作系统、所使用的客户端应用类型以及他们尝试访问的资源。 此数据应帮助你针对这些用户执行各种修正或注册操作，以便可以有效地将其纳入强制实施范围内。
计划最终用户沟通
Microsoft 为最终用户提供沟通模板。 身份验证推出材料包括可自定义的电子邮件模板，用于通知用户防网络钓鱼无密码身份验证部署。 使用以下模板与用户进行沟通，让他们了解防网络钓鱼无密码身份验证部署：
- 支持人员通行密钥
- 即将推出通行密钥
- 在 Authenticator 中注册访问密钥
- 提醒您在 Authenticator 中注册钥匙密码
应多次重复沟通，以帮助吸引尽可能多的用户。 例如，组织可以选择使用以下模式宣传不同的阶段和时间表：
- 距离强制实施还有 60 天：宣传防网络钓鱼身份验证方法的价值，鼓励用户主动注册
- 距离强制实施还有 45 天：重复消息
- 距离强制实施还有 30 天：传达 30 天后将开始强制实施防网络钓鱼措施的消息，鼓励用户主动注册
- 距离强制实施还有 15 天：重复消息，告知用户如何联系技术支持
- 距离强制实施还有 7 天：重复消息，告知用户如何联系技术支持
- 距离强制实施还有 1 天：通知用户将在 24 小时后强制实施，并告知用户如何联系技术支持
Microsoft 通过电子邮件以外的其他渠道与用户沟通。 其他选择可能包括 Microsoft Teams 消息、休息室海报和拥护者计划，在这些计划中，经过培训的所选员工会向他们的同伴宣传该计划。
报告和监视
使用以前涵盖的 Phishing-Resistant 无密码工作簿 来协助监视和报告您的部署情况。 此外，如果无法使用 Phishing-Resistant 无密码工作簿，也可以使用下面讨论的报表，或者依赖于它们。
Microsoft Entra ID 报告（例如身份验证方法活动和 Microsoft Entra 多重身份验证的登录事件详细信息）提供技术和业务见解，可帮助你衡量和推动采用。
从身份验证方法活动仪表板，可以查看注册和使用情况。
- “注册”显示支持防网络钓鱼无密码身份验证以及其他身份验证方法的用户数量。 可以看到图表，显示用户注册了哪些身份验证方法，以及每种方法最近的注册情况。
- “使用情况”显示用于登录的身份验证方法。
业务和技术应用程序所有者应根据组织要求拥有和接收报告。
- 使用身份验证方法注册活动报告跟踪防网络钓鱼无密码凭据的推出情况。
- 使用身份验证方法登录活动报告和登录日志跟踪用户对防网络钓鱼无密码凭据的采用情况。
- 使用登录活动报告跟踪用于登录多个应用程序的身份验证方法。 选择用户行；选择“身份验证详细信息”以查看身份验证方法及其相应的登录活动。
发生以下情况时，Microsoft Entra ID 会向审核日志中添加条目：
- 管理员更改身份验证方法。
- 用户在 Microsoft Entra ID 中对其凭据进行任何类型的更改。
Microsoft Entra ID 将大多数审核数据保留 30 天。 建议保留更长时间以满足审核、趋势分析和其他业务需求。
在 Microsoft Entra 管理中心或 API 中访问审核数据，并将其下载到分析系统中。 如果需要更长的保留期，请在 Microsoft Sentinel、Splunk 或 Sumo Logic 等安全信息和事件管理 (SIEM) 工具中导出和使用日志。
监视技术支持票证量
IT 技术支持可以提供有关部署进展情况的宝贵信号，因此 Microsoft 建议在执行防网络钓鱼无密码部署时跟踪技术支持票证量。
技术支持票证量增加时，应降低部署、用户沟通和强制操作的速度。 票证量减少时，可以重新增加这些活动。 使用此方法需要保持推出计划的灵活性。
例如，可以按日期范围而非具体日期分阶段执行部署和强制措施：
- 6 月 1 日至 15 日：第 1 波群体注册部署和活动
- 6 月 16 日至 30 日：第 2 波群体注册部署和活动
- 7 月 1 日至 15 日：第 3 波群体注册部署和活动
- 7 月 16 日至 31 日：已启用第 1 波群体强制措施
- 8 月 1 日至 15 日：已启用第 2 波群体强制措施
- 8 月 16 日至 31 日：已启用第 3 波群体强制措施
执行这些不同阶段时，可能需要根据打开的技术支持票证数量增加而减慢速度，然后在数量减少时恢复。 要执行此策略，Microsoft 建议为每个阶段创建一个 Microsoft Entra ID 安全组，并逐个将每个组添加到策略中。 这种方法有助于避免支持团队不堪重负。
为登录强制实施防网络钓鱼方法
防网络钓鱼无密码部署的最终阶段是强制使用防网络钓鱼凭据。
步骤 4：强制实施网络钓鱼防御措施
若要在 Microsoft Entra ID 中强制实施防网络钓鱼的凭据，主要机制是 条件访问认证强度。 Microsoft 建议根据用户/设备对方法对每个角色强制实施。 例如，强制实施推出可以遵循以下模式：
- Windows 和 iOS 上的管理员
- macOS 和 Android 上的管理员
- Windows 和 macOS 上的任何其他用户
- iOS 和 Android 上的任何其他用户
Microsoft 建议使用租户的登录数据生成所有用户/设备对的报告。 可以使用 Azure Monitor 和工作簿等查询工具。 至少尝试找出与这些类别匹配的所有用户/设备对。
请尽可能使用前面涵盖的 Phishing-Resistant 无密码工作簿 来协助执行阶段。
为每个用户创建一个列表，列出他们在工作中经常使用的操作系统。 将该列表映射到该用户/设备对的防网络钓鱼登录强制实施准备情况。
| 操作系统类型 | 准备强制实施 | 未准备强制实施 |
|---|---|---|
| Windows操作系统 | 10+ | 8.1 及更早版本、Windows Server |
| iOS | 17+ | 16 及更早版本 |
| Android | 14+ | 13 及更早版本 |
| macOS | 13+ （文图拉） | 12 及更早版本 |
| VDI | 视具体情况而定1 | 视具体情况而定1 |
| 其他 | 视具体情况而定1 | 视具体情况而定1 |
1 对于设备版本尚未准备好立即强制实施的每个用户/设备对，确定如何解决强制实施防网络钓鱼的需求。 对于旧版操作系统、虚拟桌面基础结构 (VDI) 和 Linux 等其他操作系统，请考虑以下选项：
- 使用外部硬件（FIDO2 安全密钥）强制实施防网络钓鱼
- 使用外部硬件（智能卡）强制实施防网络钓鱼
- 使用远程凭据（例如跨设备身份验证流中的通行密钥）强制实施防网络钓鱼
- 使用 RDP 隧道（尤其是 VDI）内的远程凭据强制实施防网络钓鱼
关键任务是通过数据衡量哪些用户和角色已准备好在特定平台上强制实施。 对准备好强制实施的用户/设备对开始强制实施行动，以“止血”并减少环境中出现的可网络钓鱼身份验证的数量。
然后再转向需要准备工作的用户/设备对的其他应用场景。 逐一处理用户/设备对列表，直至全面强制实施防网络钓鱼身份验证。
创建一组 Microsoft Entra ID 组以逐步推出强制实施。 如果采用分阶段的推出方法，则重复使用上一步中的组。
建议实施的条件访问策略
使用特定的条件访问策略定位每个组。 此方法可帮助你按用户/设备对逐步推出强制实施控制。
| Policy | 策略中针对的组名 | 策略 - 设备平台条件 | 策略 - 授权控制 |
|---|---|---|---|
| 1 | Windows 防网络钓鱼无密码准备就绪用户 | Windows操作系统 | 需要身份验证强度 – 防钓鱼 MFA |
| 2 | macOS 防网络钓鱼无密码准备就绪用户 | macOS | 需要身份验证强度 – 防钓鱼 MFA |
| 3 | iOS 防网络钓鱼无密码准备就绪用户 | iOS | 需要身份验证强度 – 防钓鱼 MFA |
| 4 | Android 防网络钓鱼无密码准备就绪用户 | Android | 需要身份验证强度 – 防钓鱼 MFA |
| 5 | 其他防网络钓鱼无密码准备就绪用户 | 除 Windows、macOS、iOS 或 Android 之外的任何平台 | 需要身份验证强度 – 防钓鱼 MFA |
确定每个用户的设备和操作系统是已准备就绪，还是没有该类型的设备，然后将其添加到每个组。 在推出结束时，每个用户都应加入其中一个组。
应对无密码用户的风险
Microsoft Entra ID 标识保护可帮助组织检测、调查和修正基于标识的风险。 Microsoft Entra ID 保护可为用户提供重要且有用的检测，即使这些用户转而使用防网络钓鱼无密码凭据后也是如此。 例如，针对防网络钓鱼用户的一些相关检测包括：
- 来自匿名 IP 地址的活动
- 管理员确认用户被入侵
- 异常令牌
- 恶意 IP 地址
- Microsoft Entra 威胁情报
- 可疑浏览器
- 中间攻击者
- 可能尝试访问主刷新令牌 (PRT)
- 以及其他：映射到 riskEventType 的风险检测
Microsoft 建议 Microsoft Entra ID 保护客户采取以下措施，以最好地保护其防网络钓鱼无密码用户：
- 查看 Microsoft Entra ID 保护部署指导：规划 ID 保护部署
- 配置风险日志以导出到 SIEM
- 调查并处理任何中等用户风险
- 配置条件访问策略以阻止高风险 用户
部署 Microsoft Entra ID 保护后，请考虑使用条件访问令牌保护。 随着用户使用防网络钓鱼无密码凭据登录，攻击和检测也将不断发展。 例如，当用户凭据不再容易被网络钓鱼时，攻击者可能会转而尝试从用户设备外泄令牌。 令牌保护通过将令牌绑定到所发放设备的硬件上，有助于降低这种风险。