基于本地用户库与Identity Provider的Web/移动端认证流程咨询

一、登录类型选择：优先预先询问用户，规避用户ID探测风险 #

• 推荐预先提供登录类型选项：结合你的业务场景——企业用户启用SSO后极少使用内部登录，内部登录仅服务管理场景，让用户直接选择「企业SSO登录」或「内部账号登录」是最优解。该方式逻辑直白，目标用户（尤其是企业员工）清楚自身登录渠道，不会增加过多操作成本，同时彻底避免了用户ID被批量探测的安全风险。
• 不建议先获取用户ID再判断：这种模式存在明显的用户枚举漏洞——攻击者可通过批量输入用户ID，利用系统的响应差异判断有效账号，进而发起针对性攻击。即便做防探测处理（如统一响应延迟、模糊提示），也会徒增系统复杂度，性价比极低。

二、无需构建轻量IDP层，建议搭建认证路由统一入口 #

• 绝对不要重复造轮子：OpenID Connect是成熟的标准协议，Okta、Azure AD等外部IDP已覆盖认证、令牌管理、安全合规等全流程能力。自行开发轻量IDP不仅需要投入大量精力处理令牌签名、刷新、撤销等安全细节，还极易引入未被发现的漏洞。
• 替代方案：构建认证路由层：在Web层新增一个统一的认证入口端点，移动端仅需对接该端点即可。路由层根据预设规则（如用户所属租户的SSO配置、用户类型标识）自动转发请求：
  • 若用户选择企业SSO或所属租户启用SSO，直接重定向至外部IDP的授权端点；
  • 若用户选择内部登录，转发至内部账号认证接口。
    这种方式既统一了移动端的对接逻辑，又复用了现有Web层的认证能力，完全避免重复开发。

三、移动端优先选择Bearer Token认证方案 #

• 替换Session Cookie，采用Bearer Token（推荐JWT）：当前Session方案更适配Web浏览器场景，移动端原生应用使用Session存在诸多痛点：
  • 移动端对Cookie的管理远不如浏览器便捷，跨域请求、Cookie持久化存储易出现异常；
  • Bearer Token更适配API调用场景，移动端可将Token存储在系统安全容器（iOS Keychain、Android Keystore）中，每次请求通过Authorization: Bearer <token>头传递，符合RESTful API设计规范；
  • 扩展性更强：外部IDP直接签发的Token可被移动端直接使用，无需额外适配Session创建逻辑，后续新增其他IDP也更便捷；
  • 迁移成本低：可在Web层同时支持Session和Token两种认证方式，逐步推动移动端切换至Token，不影响现有业务运行。

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