跳到主要内容

自定义登录页与认证接入

自定义登录页同时涉及：

  • 微前端接入
  • 登录入口替换
  • 本地登录、LDAP、CAS、OAuth2/OIDC 等认证方式组织
  • token、provider 和 i18n 的运行时接入

替换边界​

当前平台默认只把 /login 页面交给自定义微前端。

这意味着：

  • 你负责的是登录页视觉和交互
  • /login/callback 仍由基座负责
  • /login/bind 仍由基座负责

所以大多数自定义登录页并不需要自己实现 OAuth2、CAS 或 OIDC 的回调页，而是要把“发起登录”这一段接好。

什么时候值得做自定义登录页​

  • 需要统一企业品牌视觉
  • 需要把多种认证方式组织成更清晰的登录体验
  • 需要在登录页接入企业文案、多语言或特殊说明
  • 默认登录页已经无法满足产品级体验要求

如果你的目标只是调整某个业务页面，而不是登录体验本身，通常应先看普通微前端页面扩展，而不是从登录页切入。

一条完整接入路径​

这类需求通常建议按下面顺序推进：

  1. 先创建一个微前端应用
  2. 完成 应用改造
  3. 在平台中上传微前端包
  4. 把它配置成登录页入口
  5. 再在页面里接本地登录、LDAP 和跳转式登录能力

这里最关键的是先把“微前端可被基座稳定挂载”解决，再做认证交互。

登录方式建议怎么组织​

当前最稳妥的做法通常是把登录页拆成两块：

  • 账号密码区：承接本地登录和 LDAP 登录
  • 跳转式单点登录区：承接 CAS、OAuth2、OIDC 一类 provider

这样做的好处是：

  • 账号密码表单不会和 SSO 按钮混成一堆
  • 不同 provider 类型边界更清楚
  • 后续补多语言、错误提示和回跳逻辑也更容易维护

你真正会用到哪些运行时能力​

自定义登录页通常会依赖下面这组能力：

  • 最新 token 获取
  • 当前应用信息与配置
  • 外部 provider 列表
  • 本地登录开关判断
  • 本地登录与 LDAP 登录方法
  • 跳转式登录发起方法
  • returnUrl 清洗
  • 错误码映射
  • i18n namespace 与语言切换

一个很关键的细节是：

  • props.token 只是挂载时快照
  • 需要持续拿最新 token 时，应改用 getToken()

常见误判​

误判一：自定义登录页等于自己实现整套认证流程​

不成立。

大多数情况下，你只是替换 /login 的展示和入口发起逻辑，回调和绑定链路仍然由基座承接。

误判二：登录页做好了，微前端接入一定没问题​

不成立。

publicPath、生命周期导出、打包产物、挂载模式这些微前端基础问题，往往比登录表单本身更容易先出错。

误判三：所有登录方式都可以塞进同一个账号密码表单​

不建议。

LDAP 与跳转式 SSO 的交互语义不同，混在一起通常会让用户不清楚当前到底在走哪条认证链路。

推荐的阅读顺序​

如果你准备正式做这件事，建议按下面顺序看：

  1. 微前端应用
  2. 应用改造
  3. 平台自定义登录页集成指南

这三篇分别解决：

  • 微前端以什么形态接入
  • 前端工程如何改造成可挂载产物
  • 登录页如何接认证、token、provider 和 i18n

实施顺序​

先把“微前端稳定挂载”解决，再把“认证入口组织”解决，最后再打磨视觉和文案。

如果顺序反过来，往往会在页面已经做得很完整时，才发现接入边界和认证链路还没跑通。

下一步看哪里​