是否存在Service Principal的client secret过期后az login仍成功的情况？

确实存在以下几种明确场景会出现该现象：

• 实际登录使用的密钥与你查询到的过期密钥不是同一条
  单个服务主体支持同时创建多个客户端密钥，每条密钥有独立的过期时间和唯一标识，Azure界面默认只展示密钥的最后几位后缀。如果提供信息的人员给错了密钥对应的详情，或者你查询时没有匹配密钥后缀，很可能出现你用来登录的是另一条未过期的密钥，仅查到的记录是过期状态，造成过期密钥可用的误判。
• Azure AD存在临时凭据宽限机制
  为了避免企业密钥轮转期间业务出现非预期中断，Azure AD后台对刚过期的凭据会提供最长数小时的临时宽限窗口期，该机制没有公开的固定规则，属于后台容错策略。
• Azure CLI本地缓存了有效凭据
  如果你当前设备之前曾使用该服务主体的有效凭据完成过登录，az login 命令会优先调用本地缓存的有效访问令牌，不会实际提交你输入的过期密钥到后端做校验。你可以执行 az account clear 清除所有本地缓存后再重试登录，即可验证凭据有效性。
• 服务主体同时启用了其他认证方式
  如果该服务主体还配置了证书认证、托管身份绑定等其他有效认证策略，本地环境可能默认触发了其他认证逻辑，导致你误以为是用提交的客户端密钥完成的登录。

快速验证方案：

1. 执行 az account clear 清空本地所有凭据缓存
2. 执行 az login --service-principal -u <你的Client ID> -p <待验证的Client Secret> --tenant <你的Tenant ID> 强制提交指定密钥做认证
3. 若仍可登录成功，到Azure AD应用注册页面对比所有客户端密钥的后缀，确认你使用的密钥是否真的对应已过期的那条记录

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