Auth

上级：后端学习 from zero

Authentication 和 Authorization

前者是“认证”，证明你是谁；后者是“授权”，决定你能做什么。

Authentication: 你是谁？
Authorization: 你能对什么资源做什么操作？

Authentication

当用户或第三方服务请求 API Gateway 时，系统先通过认证服务器确认身份。身份有效，请求才会被放行到内部服务；否则返回 401 Unauthorized。

Basic Auth

客户端把 用户名:密码 做 Base64 编码，放到 Authorization: Basic <value> 中。

Base64 不是加密，可以轻易反向解码，因此必须配合 HTTPS；现代生产环境很少直接使用。

Digest Auth

服务器先发一个随机数 nonce，客户端用 nonce 和密码计算摘要，只把摘要发回服务器。它避免了密码明文传输，但依赖 MD5，流程复杂，现在也很少使用。

API Key

服务端生成一段随机字符串，客户端每次请求携带它，服务器根据 Key 查询调用方和权限。

API Key 本身通常不包含身份信息，泄露后需要主动吊销；如果每次都查数据库，还会把认证变成额外的查询瓶颈。生产环境应保存 Key 的哈希，而不是明文。

Session

Session 是服务端状态模型：

1. 用户使用账号密码登录。
2. 服务端验证通过后，在内存或 Redis 创建 Session。
3. 浏览器收到包含 Session ID 的 Cookie。
4. 后续请求自动携带 Cookie。
5. 服务端用 Session ID 查找登录状态。

它可以随时吊销，适合传统 Web；代价是服务端必须保存状态。分布式部署时不能依赖单机内存，通常需要 Redis 或其他共享存储。

Token 和 JWT

Token 认证的是“请求方持有可信系统签发的有效凭据”，不是每次重新证明自己知道密码。

要拆开几个概念：

• Session：服务端状态模型。
• JWT：一种自包含、可验签的 Token 格式。
• Cookie：浏览器保存并自动发送数据的机制。
• Bearer：HTTP 中携带认证凭据的一种方式，谁持有 Token 谁就能使用它。

常见组合包括 Cookie + Session ID、Bearer + opaque token、Bearer + JWT 和 Cookie + JWT。浏览器网页登录常见 Cookie + Session，API、移动端和服务调用常见 Authorization: Bearer + Token。

JWT 通常包含用户 ID、角色、签发时间和过期时间。服务端用密钥验证签名，不必每次查询用户表，因此易于横向扩展。但 JWT 不是加密容器，Payload 可以被读取；敏感信息不应放进去。撤销和权限即时变化也需要额外的黑名单、短过期时间或版本号设计。

Access Token 和 Refresh Token

• Access Token：寿命短，每次访问 API 携带，泄露后的窗口较小。
• Refresh Token：寿命长，只用于向认证服务器换取新的 Access Token。

浏览器场景中 Refresh Token 不要放在 localStorage，更适合放在 HttpOnly、Secure、合适 SameSite 策略的 Cookie 中；同时仍需考虑 CSRF 防护和 Token 轮换。

OAuth2 和 OIDC

OAuth2

OAuth2 是授权框架，不是认证协议。比如第三方应用想读取 Google Drive 文件，用户在 Google 的同意页面授权，应用获得 Access Token 后调用 Drive API，但这个 Token 主要表达“应用被允许做什么”。

OIDC

OIDC 构建在 OAuth2 之上，通过额外的 ID Token 表达用户身份。ID Token 通常是包含邮箱、姓名等声明的 JWT，所以“使用 Google 账号登录”背后通常是 OAuth2 + OIDC。

SSO

SSO 是用户体验模式，不是底层协议：用户在中央身份提供商 IdP 登录一次，之后访问生态内其他应用时，由 IdP 的全局 Session 帮助完成登录。

实现 SSO 常用两类协议：

• SAML：较早的企业级标准，使用 XML 格式的 Assertion 声明用户身份。
• OIDC：基于 JSON 和 JWT，更轻量，更适合现代 Web 和移动端。

登录状态如何持久化

HTTP 是无状态的，但客户端可以在每次请求中重新携带凭据，从而保持登录状态。不同认证方式的差异，在于携带什么、由谁携带，以及服务端如何验真。

认证方式	每次请求携带的凭据	载体	谁负责携带
Basic Auth	账号密码的 Base64 编码	Authorization Header	浏览器或客户端
API Key	长随机字符串	Header 或 URL 参数	调用方代码
Session	Session ID	Cookie	浏览器自动发送
JWT	签名后的 Token	Authorization: Bearer	客户端代码

客户端侧的演进，是从重复发送真实密码，转向发送可过期、可轮换、可吊销的临时凭据。服务端侧的演进，则是从每次查询 Session 或 API Key，转向在适合的场景中通过 JWT 签名直接验真。

这不意味着 JWT 永远优于 Session。JWT 降低了认证查询成本，却让即时撤销和权限实时变化更复杂；Session 需要共享状态，但撤销直接、控制力更强。选择时要看客户端类型、撤销要求和扩展规模。

Authorization

朴素权限判断的问题

最直接的授权方式，是把角色、资源所有者和部门判断写进每一个业务接口：

async function getOrder(req: Request, orderId: string) {
  const order = await db.getOrder(orderId)

  if (
    req.user.role !== "admin" &&
    req.user.id !== order.ownerId &&
    req.user.dept !== order.dept
  ) {
    throw new Error("no permission")
  }

  return order
}

async function updateOrder(req: Request, orderId: string, data: OrderInput) {
  const order = await db.getOrder(orderId)

  if (req.user.role !== "admin" && req.user.id !== order.ownerId) {
    throw new Error("no permission")
  }

  return db.updateOrder(orderId, data)
}

这种写法会逐渐产生四类问题：

1. 相似接口的规则开始分叉，形成隐蔽的权限漏洞。
2. 规则变化时，需要全局搜索并修改所有判断。
3. 部门、时间、账号状态、资源状态等条件会让判断指数膨胀。
4. 权限逻辑和业务逻辑耦合，难以复用、测试和审计。

RBAC

RBAC 是“你是什么角色，所以你能做什么”。admin、member、guest 都是角色。它简单直观，但很难表达“这个用户只能访问这三篇文章”之类的例外。

最基础的 RBAC 会直接为角色编写判断函数：

type Role = "admin" | "editor" | "viewer"

type User = {
  id: string
  name: string
  role: Role
}

function canDeleteArticles(user: User) {
  return user.role === "admin"
}

function canEditArticles(user: User) {
  return user.role === "admin" || user.role === "editor"
}

当角色和权限增多时，更好的做法是显式维护“角色拥有的权限集合”，让业务只检查权限，不关心角色名称：

const ROLES = {
  admin: [
    "view:comments",
    "create:comments",
    "update:comments",
    "delete:comments",
  ],
  moderator: ["view:comments", "create:comments", "delete:comments"],
  user: ["view:comments", "create:comments"],
} as const

type Role = keyof typeof ROLES
type Permission = (typeof ROLES)[Role][number]

function hasPermission(user: { role: Role }, permission: Permission) {
  return ROLES[user.role].includes(permission)
}

function deleteComment(user: { role: Role }, comment: Comment) {
  if (!hasPermission(user, "delete:comments")) {
    throw new Error("no permission")
  }

  return db.deleteComment(comment.id)
}

集中映射让新增角色和权限更容易，但 RBAC 仍然不擅长处理“只能删除自己的评论”“只能编辑特定组织内的文档”等资源级条件。用户、组织和角色本身可能是多对多关系；一旦角色还要绑定任意实体，权限表会快速膨胀。

ABAC

ABAC 根据四类属性综合判断：

1. Subject：用户、部门、角色、账号状态。
2. Action：查看、创建、更新、删除、审核。
3. Resource：资源类型、作者、状态等。
4. Environment：时间、IP、设备安全状态。

type Comment = {
  id: string
  body: string
  authorId: string
  createdAt: Date
}

type Todo = {
  id: string
  title: string
  userId: string
  completed: boolean
  invitedUsers: string[]
}

type Role = "admin" | "moderator" | "user"

type User = {
  id: string
  roles: Role[]
  blockedBy: string[]
}

type Permissions = {
  comments: {
    dataType: Comment
    action: "view" | "create" | "update"
  }
  todos: {
    dataType: Todo
    action: "view" | "create" | "update" | "delete"
  }
}

type PermissionCheck<Key extends keyof Permissions> =
  | boolean
  | ((user: User, data: Permissions[Key]["dataType"]) => boolean)

type RolesWithPermissions = {
  [R in Role]: Partial<{
    [Key in keyof Permissions]: Partial<{
      [Action in Permissions[Key]["action"]]: PermissionCheck<Key>
    }>
  }>
}

const ROLE_RULES = {
  admin: {
    comments: { view: true, create: true, update: true },
    todos: { view: true, create: true, update: true, delete: true },
  },
  moderator: {
    comments: { view: true, create: true, update: true },
    todos: {
      view: true,
      create: true,
      update: true,
      delete: (_user, todo) => todo.completed,
    },
  },
  user: {
    comments: {
      view: (user, comment) => !user.blockedBy.includes(comment.authorId),
      create: true,
      update: (user, comment) => comment.authorId === user.id,
    },
    todos: {
      view: (user, todo) => !user.blockedBy.includes(todo.userId),
      create: true,
      update: (user, todo) =>
        todo.userId === user.id || todo.invitedUsers.includes(user.id),
      delete: (user, todo) =>
        (todo.userId === user.id || todo.invitedUsers.includes(user.id)) &&
        todo.completed,
    },
  },
} as const satisfies RolesWithPermissions

export function hasPermission<Resource extends keyof Permissions>(
  user: User,
  resource: Resource,
  action: Permissions[Resource]["action"],
  data?: Permissions[Resource]["dataType"]
) {
  return user.roles.some((role) => {
    const permission = (ROLE_RULES as RolesWithPermissions)[role][resource]?.[
      action
    ]

    if (permission == null) return false
    if (typeof permission === "boolean") return permission
    return data != null && permission(user, data)
  })
}

const user: User = { id: "1", roles: ["user"], blockedBy: ["2"] }
const todo: Todo = {
  id: "3",
  title: "Test Todo",
  userId: "1",
  completed: false,
  invitedUsers: [],
}

hasPermission(user, "comments", "create")
hasPermission(user, "todos", "view", todo)

规则不只存 true 或 false，也能根据资源属性动态计算。比如“用户只能在评论发布后 24 小时内修改自己的评论”，只需要把时间条件加入 update 规则，而不必新增一张权限关系表。

ABAC 适合把业务条件写成策略，避免每增加一个模块就复制一套权限表；但上面的实现仍然把规则挂在角色下面，并且需要明确多角色冲突时的优先级。

PBAC

PBAC（Policy-Based Access Control）进一步把角色与权限规则解耦。每条 Policy 独立描述资源、操作、效果和适用条件，由统一的 Policy Engine 求值：

type Policy<Resource extends keyof Permissions = keyof Permissions> = {
  resource: Resource
  action: Permissions[Resource]["action"]
  effect: "allow" | "deny"
  condition?: (
    user: User,
    data: Permissions[Resource]["dataType"]
  ) => boolean
}

const POLICIES: Policy[] = [
  {
    resource: "comments",
    action: "update",
    effect: "allow",
    condition: (user, comment) => comment.authorId === user.id,
  },
  {
    resource: "todos",
    action: "delete",
    effect: "allow",
    condition: (user, todo) =>
      user.roles.includes("moderator") && todo.completed,
  },
  {
    resource: "todos",
    action: "delete",
    effect: "allow",
    condition: (user, todo) =>
      (todo.userId === user.id || todo.invitedUsers.includes(user.id)) &&
      todo.completed,
  },
]

export function evaluatePolicies<Resource extends keyof Permissions>(
  user: User,
  resource: Resource,
  action: Permissions[Resource]["action"],
  data?: Permissions[Resource]["dataType"]
): boolean {
  const matchedPolicies = POLICIES.filter(
    (policy) => policy.resource === resource && policy.action === action
  )

  if (matchedPolicies.length === 0) return false

  for (const policy of matchedPolicies) {
    const conditionPassed =
      !policy.condition || (data != null && policy.condition(user, data))

    if (!conditionPassed) continue
    if (policy.effect === "deny") return false
    if (policy.effect === "allow") return true
  }

  return false
}

Policy 可以来自代码、配置或专门的策略服务。实现时通常采用默认拒绝，并明确 deny 是否覆盖 allow，否则不同策略的组合很容易产生安全歧义。

ReBAC

ReBAC 关注“你和资源是什么关系”。在 Google Drive 一类系统中，文档可能嵌套在文件夹里，并继承祖先文件夹的权限。若把所有祖先 ID 都存成文档属性，每次移动文档都要重新计算；若在 ABAC 判断中递归加载父节点，策略求值又会变成维护噩梦。

type ObjectType = "document" | "folder" | "organization"
type Relation = "owner" | "editor" | "viewer" | "member" | "parent"

type RelationTuple = {
  object: { type: ObjectType; id: string }
  relation: Relation
  subject: { type: "user" | ObjectType; id: string }
}

const relationTuples: RelationTuple[] = [
  {
    object: { type: "folder", id: "eng-folder" },
    relation: "owner",
    subject: { type: "user", id: "alice" },
  },
  {
    object: { type: "folder", id: "eng-folder" },
    relation: "editor",
    subject: { type: "user", id: "bob" },
  },
  {
    object: { type: "document", id: "doc-1" },
    relation: "parent",
    subject: { type: "folder", id: "eng-folder" },
  },
  {
    object: { type: "document", id: "doc-1" },
    relation: "editor",
    subject: { type: "user", id: "david" },
  },
]

ReBAC 通常定义三种东西：

• Object：被保护的对象，例如文档、文件夹、组织。
• Relation：用户与对象的关系，例如 owner、editor、viewer。
• Rule：如何从已有关系推导出新关系，例如“父文件夹的 editor 也是子文档的 editor”。

以 Notion 为例

Notion 的权限系统实际上会组合多种模型：

• RBAC 处理 workspace owner、admin、member、guest 等工作区角色。
• ABAC 处理公司邮箱域、页面是否公开、内容是否敏感、是否允许外部分享等属性和环境条件。
• ReBAC 处理页面直接邀请、Group 授权、父子页面权限继承、Teamspace 成员关系和公开链接访问。

其中页面共享、数据库共享、团队空间协作、页面树继承和外部访客访问，最接近 ReBAC。比如“你在这个团队里，而团队对文档有编辑权限，所以你能编辑”，就是从关系推导权限，而不是只查看用户角色。

选择时的顺序

先明确认证对象、凭据生命周期、撤销需求和客户端类型，再选择 Session 或 Token；授权则从 RBAC 起步，只有当资源属性或实体关系确实复杂时，再引入 ABAC 或 ReBAC。安全设计的核心不是追逐最复杂的方案，而是让凭据、权限和失败处理都可验证、可撤销、可审计。