测验：认证方式全景

为什么用 OAuth 2.0 访问令牌判断“登录成功”很危险？

• 访问令牌没有到期时间，一经签发便永久有效
• 访问令牌以明文传输，因此会被中途读取
• 访问令牌无法保存在服务器上，所以不能与会话关联
• 它用于授权，对“签发给谁”的证明较弱，其他应用的令牌可能被拿来使用

在传统 WebSSO 的请求头注入方式（如 SM_USER）中，以下哪项不是必需的控制措施？

• 通过网络隔离，确保除网关外无法访问应用端口
• 在边缘无条件删除外部传入的认证请求头，再重新写入
• 应用对请求头值进行 base64 编码后再传递
• 在网关与应用之间进行双向认证（mTLS 或共享密钥）

LDAP 认证与基于 OIDC 的 SSO 最实质的区别是什么？

• LDAP 一次查询即可完成，往返较少，因此登录更快
• LDAP 只提供用户属性，不能提供组和角色信息
• LDAP 由应用直接接收并验证密码，OIDC 则不让应用接触密码
• OIDC 必须使用公共 IdP，因此断网的内网无法使用

切换到 SSO 三周后，月末突然出现认证失败。最可能的原因是什么？

• 仅在月末运行的批处理或集成程序模拟人工登录，却遗漏在切换范围之外
• 引入 SSO 时签发的证书恰好在此时到期
• 月末结算导致并发登录激增，超过 IdP 的并发会话上限
• 浏览器中残留的旧会话 Cookie 到期并引发冲突

把 SM_USERGROUPS: hr-staff^payroll-admin 按逗号分隔解析，会得到什么结果？

• 整个字符串被识别为一个组名，所有权限判断都失败
• 正常识别出两个组
• 发生解析异常并阻止登录
• 只识别第一个组

客户已经运行 SAML IdP，而只有我们的系统是新建系统时，最现实的选择是什么？

• 要求客户改用 OIDC
• 让我们的系统作为 SAML SP 接入
• 在我们的系统中另建用户名和密码
• 直接通过 LDAP bind 连接客户的 AD