服务器MFA不可排除，需区分人机认证路径：人为交互式MFA，机器用OAuth Client Credentials、API Key或短期令牌，并通过服务主体最小权限授权与策略排除实现安全自动化。
服务器端的多因素认证（MFA）本身不应被“排除”——这是安全底线。真正需要解决的，是让自动化脚本和 API 调用在不触发交互式 MFA 的前提下，合法、安全、可持续地完成身份验证。
明确区分：人 vs 机器的身份验证路径
系统应为人类用户和机器服务提供不同的认证通道。MFA 是为人设计的，不是为服务账户或 API 客户端设计的。关键在于避免把面向人的登录流程（如浏览器表单 + TOTP 输入）错误复用于自动化场景。
- 禁止给服务账号配置短信、推送或 TOTP 类 MFA —— 这类因素无法由脚本可靠生成或响应；
- 为 API 访问单独启用基于密钥或令牌的认证机制，例如 OAuth 2.0 Client Credentials 流、API Key、或短期有效的访问令牌（Access Token）；
- 确保身份提供者（如 Microsoft Entra ID、Okta、Keycloak）支持“服务主体”（Service Principal）或“机器对机器”（m2m）应用注册，并分配专用权限范围（scopes）。
使用长期凭证 + 权限最小化原则
自动化脚本可使用非交互式凭证，但必须严格管控生命周期与权限：
- 使用客户端 ID + 客户端密钥（Client Secret），或更安全的私钥 JWT（如 OAuth 2.0 Private Key JWT），代替用户名/密码组合；
- 客户端密钥绝不硬编码在脚本中，应通过环境变量、密钥管理服务（如 HashiCorp Vault、AWS Secrets Manager）注入；
- 为每个自动化任务创建独立的服务主体，仅授予其执行所需操作的最小权限（例如只读某存储桶，而非整个云租户管理员）；
- 定期轮换密钥，设置自动过期策略（如 90 天），禁用长期有效的静态密码或 API Key。
利用会话令牌或短期访问凭证
某些平台允许通过一次人工完成 MFA 后，换取可用于脚本的短期凭证：
- AWS CLI 支持
aws sts get-session-token（需 MFA），返回临时 AccessKeyId/SecretKey/SessionToken，有效期最长 36 小时； - Azure CLI 使用
az login --use-device-code或az login --identity（托管标识）绕过交互式 MFA； - Google Cloud 支持通过
gcloud auth application-default login --brief获取短期凭据，或使用服务账号密钥 JSON 文件（需提前禁用该账号的 MFA）； - 关键前提：这些方式依赖后端策略允许“MFA 授权后发放机器可用令牌”，而非前端绕过 MFA。
检查并关闭不适用的 MFA 强制策略
很多组织误将面向用户的条件访问策略（如“所有用户登录必须 MFA”）泛化到服务主体或特定 IP/应用上，导致 API 调用失败：
- 在 Microsoft Entra ID 中，通过条件访问策略排除“云应用”类型为“API”或“服务主体”的流量；
- 在 Okta 中，为自动化应用配置“不受 MFA 策略影响”的信任策略（Trusted Applications）；
- 确认 API 网关（如 Kong、Apigee）或 IAM 网关未对 /token、/oauth2/token 等认证端点强制校验 MFA 状态；
- 若使用反向代理或自建认证中间件，确保其未对 client_credentials 流误加 MFA 校验逻辑。
