Authentication

Bedrud 支持多种认证方式。

JWT（JSON Web Tokens）

Bedrud 使用 JWT 进行会话管理。登录时，服务器返回两个令牌：

Access Token： 短期有效（例如 1 小时）。用于访问受保护的 API 端点。
Refresh Token： 长期有效（例如 30 天）。用于在无需重新登录的情况下获取新的 Access Token。

后端在 internal/middleware/auth.go 文件中验证这些令牌。

令牌管理与安全性

1. 令牌对策略（Rotation）

Bedrud 使用安全的令牌轮换策略。用户认证时，会收到：

Access Token： 使用 HS256 签名，包含用户 ID、名称和权限。有效期较短（通过 tokenDuration 配置）。
Refresh Token： 一个独立的长期令牌。

轮换机制： 当 Access Token 过期时，客户端将 Refresh Token 发送到 /api/auth/refresh。服务器随后签发一对全新的令牌，并更新数据库中存储的 refresh token。即使令牌被盗，这也限制了可利用的时间窗口。

2. 令牌撤销（Blacklisting）

为了支持安全的登出，Bedrud 实现了令牌黑名单。

当用户登出时，其当前的 Refresh Token 会被添加到 blocked_refresh_tokens 表中。
在刷新任何会话之前，服务器会检查此表。如果令牌已被阻止，请求将立即被拒绝。
后台任务（Scheduler）负责在这些被阻止的令牌自然过期后进行清理。

3. JWT Claims 结构

令牌携带元数据，允许后端和前端无需查询数据库即可快速做出决策：

{
  "userId": "uuid-string",
  "email": "user@example.com",
  "name": "Display Name",
  "accesses": ["user", "admin"],
  "exp": 123456789,
  "iat": 123456780
}

认证方式

1. 邮箱密码登录

密码使用 bcrypt 进行哈希处理—从不以明文存储。
注册时，会在数据库中创建新的用户记录。

2. 社交登录（OAuth2）

Bedrud 使用 Goth 库支持：

Google
GitHub
Twitter

你可以在 config.yaml 中填写 auth: 部分的 Client ID 和 API Secret 来启用它们。

3. Passkeys（WebAuthn/FIDO2）

Bedrud 通过 FIDO2 标准（WebAuthn）支持无密码认证。

注册流程：
1. 开始： 服务器生成一个加密安全的 Challenge 并将其存储在用户会话中。
2. 完成： 客户端的 authenticator（如 TouchID、YubiKey）对 challenge 进行签名。服务器验证 attestation，提取公钥，并将其保存在 passkeys 表中。
认证流程：
1. 开始： 服务器签发一个新的 challenge。
2. 完成： 客户端使用私钥对 challenge 进行签名。服务器从数据库中检索公钥，验证签名，并检查签名计数器。
安全性： Counter 字段的匹配可以防止重放攻击。如果 authenticator 的计数器不高于存储的计数器，则登录将被拒绝。

4. 访客登录

允许用户仅通过输入名称即可立即加入会议。服务器创建一个具有 guest 角色的临时用户记录。

互操作性与 CORS

Bedrud 设计为可从多个来源访问，这对于开发环境（React 开发服务器）和生产环境（不同子域名）至关重要。

CORS 策略： 在 config.yaml 中定义。它支持 AllowCredentials: true，这是 OAuth 和 Passkey 流程中使用的会话 cookie 所必需的。
允许的来源： 默认情况下，允许服务器自身的域名和 localhost:3000（React 开发服务器端口）。

用户角色（访问控制）

每个用户都有一组”accesses”（角色）。

user：标准用户。可以加入和创建房间。
guest：临时用户。可以加入房间。
superadmin：可以通过 /admin 仪表板管理所有用户和房间。

middleware.RequireAccess("superadmin") 守卫用于保护管理员路由。