设计一个校园科研管理系统的用户认证与授权流程，要求支持多端（PC、移动端）访问，并确保安全性。请从用户登录开始，描述完整的流程，并说明各环节的技术选型（如认证协议、令牌类型）。

深圳大学宝钢股份难度：中等

答案

1) 【一句话结论】针对校园科研管理系统多端访问的安全需求，采用OAuth 2.0 + JWT + 令牌黑名单的方案，通过中心化认证服务实现统一登录、角色授权，并保障令牌存储与传输安全。

2) 【原理/概念讲解】老师口吻，解释核心是“统一认证、分离授权”。用户登录时，前端提交凭证到认证服务，服务验证身份后生成包含角色信息的JWT（如payload包含roles数组），前端存储加密后的令牌（移动端用Android Keystore + AES-256-GCM），后续请求携带令牌到后端，后端验证令牌（检查黑名单、签名、过期时间）并从payload提取角色，根据角色过滤资源（学生仅访问课程数据，管理员可访问全部）。类比：就像校园实验室的“电子门禁卡”，先验证身份（登录），再根据卡类型（角色）进入不同区域（授权），多端设备都能使用同一张“卡”。

3) 【对比与适用场景】

认证协议选择OAuth 2.0 + JWT的原因：支持多端、无状态、自包含，适合API和移动端；
令牌存储加密：移动端使用Android Keystore管理密钥，通过AES-256-GCM加密令牌，防止本地窃取；
令牌黑名单：认证服务维护黑名单列表，验证令牌时检查是否在黑名单中，防止重放攻击。

4) 【示例】

用户登录（PC端）：
前端发送HTTPS POST请求到认证服务/auth/login，携带用户名和密码：
```
{
  "username": "student001",
  "password": "password123"
}
```
认证服务验证成功后返回JWT：
```
{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLzE2LjI0IiwiaWF0IjoxNjIzNjQwMDAwfQ.abc123",
  "token_type": "Bearer",
  "expires_in": 3600,
  "roles": ["student", "researcher"]
}
```
PC端将access_token存储在LocalStorage（加密，如使用AES-256-GCM），后续请求头添加Authorization: Bearer abc123。
后端验证流程：
后端收到请求后，先检查令牌是否在黑名单中（认证服务维护黑名单，如令牌被窃取后加入），验证签名和过期时间，从payload提取roles字段，根据角色过滤资源（如学生请求课程数据，管理员请求全部数据）。

5) 【面试口播版答案】
“面试官您好，针对校园科研管理系统的多端认证与授权，我建议采用OAuth 2.0 + JWT + 令牌黑名单的组合方案。核心思路是：用户登录时，前端提交凭证到中心化认证服务，服务验证身份后生成包含角色信息的JWT，前端存储加密后的令牌（移动端用Android Keystore + AES-256-GCM），后续所有请求携带令牌到后端，后端验证令牌（检查黑名单、签名、过期时间）并从payload提取角色，根据角色过滤资源。这样既支持PC和移动端，又确保了安全性和授权粒度。”

6) 【追问清单】

问题：如何实现角色授权（如学生和老师权限不同）？
回答要点：JWT的payload中包含roles数组，后端根据roles字段过滤资源（如学生只能访问个人课程数据，老师可访问所有课程数据）。
问题：移动端令牌存储如何保证安全？
回答要点：使用Android Keystore存储加密密钥，通过AES-256-GCM加密令牌，防止本地窃取。
问题：令牌被窃取后如何防止滥用？
回答要点：引入令牌黑名单机制，认证服务维护黑名单列表，验证令牌时检查是否在黑名单中，防止重放攻击。
问题：多端同时登录时如何处理？
回答要点：采用单点登录（SSO），认证服务记录登录设备，若检测到新设备登录，提示用户或强制下线原设备。

7) 【常见坑/雷区】

忽略授权粒度：只验证用户身份，未区分角色权限，导致资源泄露；
令牌存储未加密：直接存储明文令牌，被窃取后可冒充用户；
未考虑令牌黑名单：令牌被窃取后长期有效，无法及时撤销；
多端认证逻辑不一致：PC和移动端使用不同认证流程，导致体验不一致；
密钥管理不当：JWT密钥未定期轮换，导致令牌被破解。