课程地图 身份、权限与安全
场景库 术语表
M2 · Chapter 05

身份、权限与安全

理解系统如何判断你是谁、能做什么,并保护数据边界。

6 个小节10 个业务案例7 类业务场景设计师视角
先看哪些场景

企业审批、账号与权限、多租户 SaaS、项目与协作、内容与媒体等场景

它是什么

身份认证确认主体,授权决定主体对资源可以执行哪些操作,安全机制保护通信、数据和运行环境。

为什么需要

登录、角色、按钮显隐、数据范围和敏感操作都依赖完整权限模型。

位于哪一层

横跨客户端、API、后端、数据库和基础设施。

和谁连接

Cookie、Session、Token、JWT、OAuth、SSO、RBAC、ABAC、Hash、Encryption 和常见攻击。

项目里怎么出现

企业后台的管理员、项目成员、审批人和访客会看到不同数据与操作。

Learning Outcomes

学完这一章,你应该能

  • 区分 Authentication 与 Authorization
  • 理解 Session、Cookie、Token 与 JWT
  • 理解 OAuth、SSO、RBAC 与 ABAC
  • 认识常见安全问题和保护方式
05.01

Authentication 与 Authorization

认证回答“你是谁”,授权回答“你可以做什么”。

Business Scenario First

先从真实业务问题进入

先看用户动作和业务风险,再理解技术为什么出现,以及它会怎样改变页面、状态和流程。

企业审批CASE 01

员工能登录报销系统,为什么仍然看不到财务审批页?

用户正在做什么

员工成功登录,只能查看自己的报销单;财务可以审核全公司的报销。

业务会出什么问题

把“已登录”和“有权操作”混为一谈会造成越权访问。

技术怎样介入

Authentication 确认用户身份,Authorization 根据 Principal、角色和资源判断权限。

产品与设计怎样落地

无权限时要决定隐藏入口、禁用操作或展示申请权限,并避免泄露敏感信息。

用户登录后,系统确认身份并建立会话。每次访问资源时,后端根据身份、角色、资源归属和上下文判断是否允许。

权限需要覆盖接口和数据范围。项目成员能查看当前项目,管理员能管理全部项目,访客可能只能读取公开内容。

Login → Identity → Permission Check → Resource
System View

Authentication

  • 确认主体
  • 登录、设备、凭证
  • 建立身份上下文

Authorization

  • 判断操作权限
  • 角色、属性、资源
  • 控制数据和行为
Designer Lens

按钮显隐是权限结果的界面表达,后端权限规则才是最终边界。

AuthenticationAuthorizationPrincipal
05.03

JWT、OAuth 与 SSO

JWT 是凭证格式,OAuth 是授权流程,SSO 是统一登录体验。

Business Scenario First

先从真实业务问题进入

先看用户动作和业务风险,再理解技术为什么出现,以及它会怎样改变页面、状态和流程。

账号与权限CASE 01

“使用 Google 登录”背后发生了什么?

用户正在做什么

用户不想注册新密码,选择 Google 登录。

业务会出什么问题

你的系统不能直接获取用户的 Google 密码,也需要确认授权范围。

技术怎样介入

OAuth 让 Google 在用户授权后返回凭证,你的系统再创建或绑定本地账号;JWT 可承载签名后的身份声明。

产品与设计怎样落地

设计授权范围、账号已存在、取消授权、绑定冲突和登录回跳。

多租户 SaaSCASE 02

企业员工为什么登录一次就能进入多个内部系统?

用户正在做什么

员工已登录公司身份平台,再打开项目系统和财务系统。

业务会出什么问题

每个系统重复登录会增加使用成本和账号管理风险。

技术怎样介入

SSO 让多个应用信任统一身份提供方,企业可以集中停用账号和执行安全策略。

产品与设计怎样落地

要设计组织选择、身份过期、账号无权限和离职后访问撤销。

JWT 包含 Header、Payload 和签名,服务端可以验证内容是否被篡改。它不自动解决权限、撤销和安全存储问题。

OAuth 让用户授权第三方应用访问有限能力,常用于 Google、GitHub 或微信登录。SSO 让多个企业系统共享统一身份入口。

Identity Provider → Authorization Flow → Application Session
System View
JWT:Token 格式
OAuth 2.0:授权协议
OpenID Connect:身份层
SSO:多系统统一登录
Identity Provider:身份提供方
Callback:登录完成回调
Designer Lens

第三方登录页面要清楚表达来源、授权范围、失败和账号绑定。

常见混淆 · JWT 是否等于 OAuth?

JWT 是数据格式;OAuth 是授权流程;两者可以一起使用,也可以分别使用。

JWTOAuthSSO
05.04

RBAC 与 ABAC

角色权限适合稳定分工,属性权限适合动态业务条件。

Business Scenario First

先从真实业务问题进入

先看用户动作和业务风险,再理解技术为什么出现,以及它会怎样改变页面、状态和流程。

项目与协作CASE 01

项目经理和普通成员为什么看到不同按钮?

用户正在做什么

项目经理可以编辑计划和邀请成员,普通成员只能更新自己的任务。

业务会出什么问题

权限散落在页面判断中容易遗漏,后端也可能被绕过。

技术怎样介入

RBAC 把权限分配给角色;更细的 ABAC 可根据项目归属、部门、金额和时间动态判断 Policy。

产品与设计怎样落地

设计权限矩阵,明确按钮隐藏、禁用、申请权限和数据范围。

企业审批CASE 02

为什么“财务可审批”还要加金额条件?

用户正在做什么

普通财务可审批五万元以下报销,大额需要财务负责人。

业务会出什么问题

单纯角色无法表达金额、部门和单据状态等上下文条件。

技术怎样介入

ABAC 根据角色、金额、部门、资源状态等属性执行策略。

产品与设计怎样落地

审批页要展示当前审批链、升级原因和下一处理人。

RBAC 把权限分配给角色,再把角色分配给用户。它易于理解和管理,适合管理员、编辑、访客等常见模型。

ABAC 根据用户、资源、动作和环境属性判断,例如“项目负责人可以在项目未结项时修改预算”。复杂系统常把角色、数据范围和业务条件组合。

User → Role → Permission → Resource;Attributes → Policy Decision
System View

RBAC

  • 围绕角色
  • 配置直观
  • 适合稳定职责

ABAC

  • 围绕属性与规则
  • 表达动态条件
  • 适合复杂资源与上下文
Designer Lens

权限设计需要同时交付角色矩阵、数据范围、操作条件和无权限反馈。

RBACABACPolicy
05.05

常见 Web 安全问题

安全问题来自不可信输入、伪造请求、错误权限和敏感信息暴露。

Business Scenario First

先从真实业务问题进入

先看用户动作和业务风险,再理解技术为什么出现,以及它会怎样改变页面、状态和流程。

内容与媒体CASE 01

评论区为什么不能直接渲染用户输入的脚本?

用户正在做什么

攻击者在评论里提交一段恶意 JavaScript。

业务会出什么问题

如果页面直接执行,可能窃取登录信息或冒充用户操作。

技术怎样介入

服务端和前端对内容转义、过滤并采用安全策略,防止 XSS。

产品与设计怎样落地

富文本编辑器要明确允许格式,危险内容被清理时给出可理解提示。

订单与支付CASE 02

用户已登录银行网站,恶意页面能否替他发起转账?

用户正在做什么

用户保持登录状态时访问了攻击者页面。

业务会出什么问题

浏览器可能自动携带 Cookie,恶意页面诱导发送请求,形成 CSRF。

技术怎样介入

使用 CSRF Token、SameSite Cookie 和敏感操作二次确认;参数化查询防止 SQL Injection。

产品与设计怎样落地

转账、删除和权限变更等操作需要明确确认、风险提示和操作结果。

XSS 利用未安全处理的内容执行脚本;CSRF 借用用户已登录状态发起伪造操作;SQL Injection 把恶意输入拼进数据库查询。

CORS 控制浏览器跨域访问,它属于浏览器安全策略。输入校验、输出编码、参数化查询、CSRF Token 和合理 Header 可以降低风险。

Untrusted Input → Validation / Encoding / Parameterized Query
System View
XSS:脚本注入
CSRF:伪造已登录请求
SQL Injection:查询注入
CORS:跨域访问策略
Rate Limit:限制滥用
Audit Log:记录敏感操作
Designer Lens

富文本、链接、文件上传和第三方嵌入都需要明确安全边界和错误提示。

XSSCSRFSQL Injection
05.06

Hash、Encryption、Secret 与审计

不同机制分别保护密码、数据、密钥和操作可追溯性。

Business Scenario First

先从真实业务问题进入

先看用户动作和业务风险,再理解技术为什么出现,以及它会怎样改变页面、状态和流程。

安全与审计CASE 01

密码、身份证文件和支付密钥应该怎样保存?

用户正在做什么

系统同时保存用户密码、加密后的身份证附件和第三方支付 API 密钥。

业务会出什么问题

明文保存会在数据库或代码泄露时造成直接损失。

技术怎样介入

密码使用不可逆 Hash;敏感数据使用 Encryption;Secret 放入专用配置或密钥管理服务。

产品与设计怎样落地

产品要提供密码重置、密钥轮换、敏感信息脱敏和访问记录。

企业审批CASE 02

谁在什么时候把合同金额改了?

用户正在做什么

合同审批后金额发生变化,管理员需要追溯操作人和变更前后内容。

业务会出什么问题

只有最终数据无法解释过程,也无法满足合规和争议处理。

技术怎样介入

Audit Log 记录操作者、时间、资源、动作、前后值和请求标识。

产品与设计怎样落地

历史记录页需要可筛选、可比较,并明确哪些操作不可撤销。

密码通常进行单向 Hash 并加盐,系统不需要恢复原文。Encryption 可以在持有密钥时恢复数据,适合保护敏感字段和传输。

API Key、数据库密码和签名密钥属于 Secret,应由环境或密钥管理系统保存。Audit Log 记录谁在何时对什么资源做了什么操作。

Password → Hash;Sensitive Data → Encryption;Credential → Secret Manager;Action → Audit Log
System View
身份认证
授权策略
输入与接口防护
数据加密与密钥管理
审计、监控与响应
Designer Lens

敏感操作确认、日志可见性和权限变更历史都是安全体验的一部分。

HashEncryptionSecretAudit Log
Chapter Recap

本章小结

  • 01
    认证确认身份,授权控制资源和操作。
  • 02
    Cookie、Session、Token 与 JWT 解决会话和凭证问题。
  • 03
    OAuth、SSO、RBAC 与 ABAC 解决跨系统身份和权限策略。
  • 04
    安全需要覆盖输入、接口、数据、密钥和审计。
Practice

把认知变成一张图

为一个项目管理系统写出管理员、负责人、成员、访客四个角色的查看、编辑、删除和成员管理权限矩阵。

Quick Check

随堂检查

QUESTION 01
“用户能否删除这个项目”属于哪类问题?
删除权限属于授权判断。
QUESTION 02
密码通常应如何保存?
密码应使用专门的密码 Hash 算法处理。