3、用户认证机制：用户名密码认证、多因素认证(MFA)、单点登录(SSO)集成
用户认证，说白了就是「你怎么证明你是你」。这是大屏系统的第一道门，也是最容易被攻破的一环。我这些年做安全审计，见过太多因为认证没做好导致数据泄露的案例。今天咱们就把三种主流认证方式掰开揉碎了讲清楚。
3.1 用户名密码认证：最基础也最危险
用户名加密码，这玩意儿从计算机诞生就有了。但你别小看它，很多大屏系统出事，恰恰就出在这个最基础的环节上。
我在项目中遇到过一家公司，他们的数据大屏用的是「admin/123456」这种组合。你想想看，这跟把钥匙挂在门上有什么区别？
好的密码策略应该包含以下几点：
- 复杂度要求：至少12位，混合字符类型
- 历史记录：不能重复使用最近5次密码
- 过期机制：90天强制更换一次
- 锁定策略：连续5次失败，账户锁定15分钟
嗯，这里要注意，密码存储绝对不能明文。我建议用bcrypt或Argon2这种慢哈希算法。别用MD5，那玩意儿现在用GPU几秒钟就能破解。
// 密码哈希示例（Node.js）
const bcrypt = require('bcrypt');
const saltRounds = 12;
async function hashPassword(password) {
const salt = await bcrypt.genSalt(saltRounds);
const hash = await bcrypt.hash(password, salt);
return hash;
}
async function verifyPassword(password, hash) {
return await bcrypt.compare(password, hash);
}3.2 多因素认证(MFA)：加把锁更安心
光靠密码不够，那就再加一道验证。这就是多因素认证的核心思想——「你知道的 + 你拥有的 + 你本身的」。
我个人习惯把MFA分成三个维度：
| 因素类型 | 举例 | 安全性 |
|---|---|---|
| 知识因素 | 密码、PIN码 | 低 |
| 持有因素 | 手机、硬件Token | 中 |
| 生物因素 | 指纹、人脸 | 高 |
大屏系统我建议至少启用两种因素。比如密码 + 手机验证码，或者密码 + 指纹。为什么？因为单靠密码太容易被钓鱼了。
实现TOTP（基于时间的一次性密码）其实不复杂：
// TOTP生成示例
const speakeasy = require('speakeasy');
// 生成密钥
const secret = speakeasy.generateSecret({ length: 20 });
console.log('Secret:', secret.base32);
// 生成验证码
const token = speakeasy.totp({
secret: secret.base32,
encoding: 'base32'
});
// 验证
const verified = speakeasy.totp.verify({
secret: secret.base32,
encoding: 'base32',
token: userInputToken,
window: 1 // 允许前后1个时间窗口的误差
});3.3 单点登录(SSO)：一次登录，处处通行
你想想看，如果公司有十几个系统，每个都要单独登录，那得多崩溃？SSO就是为了解决这个问题的。用户只需要登录一次，就能访问所有关联系统。
主流SSO协议有三种：
- SAML 2.0：企业级应用的老大哥，基于XML
- OAuth 2.0：互联网应用的主流，基于Token
- OpenID Connect：OAuth 2.0的升级版，加了身份层
我个人比较推荐OAuth 2.0 + OpenID Connect的组合。为什么呢？因为SAML的XML解析太容易出安全漏洞了，我在项目中就遇到过XML外部实体注入的问题。
下面是一个OAuth 2.0授权码流程的简化实现：
// OAuth 2.0 授权码流程
// 1. 用户点击"使用SSO登录"
// 2. 重定向到授权服务器
const authUrl = `https://auth.example.com/authorize?
response_type=code&
client_id=YOUR_CLIENT_ID&
redirect_uri=https://dashboard.example.com/callback&
scope=openid%20profile&
state=random_state_string`;
// 3. 用户授权后，回调到redirect_uri
// 4. 用code换取access_token
const tokenResponse = await fetch('https://auth.example.com/token', {
method: 'POST',
headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
body: new URLSearchParams({
grant_type: 'authorization_code',
code: receivedCode,
redirect_uri: 'https://dashboard.example.com/callback',
client_id: 'YOUR_CLIENT_ID',
client_secret: 'YOUR_CLIENT_SECRET'
})
});
// 5. 验证id_token并获取用户信息
const { access_token, id_token } = await tokenResponse.json();
// 解码JWT，验证签名，提取用户信息3.4 三种认证方式的选型建议
说了这么多，到底该怎么选？我根据项目经验总结了一张表：
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 内部管理大屏 | 密码 + MFA | 成本低，安全性足够 |
| 多系统集成大屏 | SSO + MFA | 统一管理，体验好 |
| 对外展示大屏 | 密码 + 设备绑定 | 简化流程，控制访问范围 |
| 高安全等级大屏 | SSO + 硬件Token + 生物识别 | 三重保障，万无一失 |
最后说一句，认证机制不是越复杂越好。你得在安全性和用户体验之间找平衡。我见过有些系统搞了四重认证，结果用户每天光登录就要花5分钟，最后大家都把密码贴在显示器上——这反而更不安全了。
嗯，关于用户认证机制，今天就聊到这儿。下一章咱们讲讲授权和权限控制，那才是真正决定「你能看什么数据」的关键环节。