keslr_connect 是一个用于接入 Keslr 身份与私有网络能力的 TypeScript 仓库，包含三个包：@keslr/auth、@keslr/express、@keslr/network，以及一个 guestbook 示例。它支持通过 Keslr 进行 OIDC 登录，读取用户是否为“真实且经担保验证的人类”的声明；也支持在 Keslr 私有网络中根据请求来源地址解析成员身份。当前项目处于 pre-release，尚未发布到 npm，需要从源码构建和本地引用，API 在 1.0 前可能变化。
适用领域
身份认证 / OIDC / OpenID Connect / 反机器人 / 真人验证 / 私有网络服务 / Express 中间件 / TypeScript SDK / 信任图谱 / 会员制社区应用
配置难度
中等。熟悉 Node.js、Express、OIDC、session/cookie 和网络部署的开发者可以较快上手；但由于尚未发布 npm、需要申请 Keslr 开发者权限、配置 DNS、区分 OIDC 与 network client，并正确处理私有网络绑定，完整生产接入难度高于普通第三方登录 SDK。
商业价值
该项目的核心商业价值在于帮助应用快速接入“已验证真人”身份能力，降低垃圾注册、机器人、刷帖、恶意评论和低质量内容治理成本。对于社区、论坛、邀请制产品、轻量协作工具、内部应用和只面向可信真人的服务，它可以减少账号系统、邮箱验证、验证码和人工审核的复杂度。但其价值高度依赖 Keslr 网络的用户规模、开发者准入、稳定性和目标市场接受度。对于中国开发者，建议先验证 Keslr 在目标用户群中的覆盖率、网络访问质量、合规风险和商业可持续性，再决定是否作为核心身份基础设施。
01
技术亮点
- 提供 OIDC 登录、Express 集成和网络身份解析三种核心能力
- @keslr/auth 零运行时依赖，适合希望减少供应链风险的项目
- 安全设计较强：强制 PKCE S256、固定 RS256、不信任 JWT alg header、state/nonce 常量时间比较
- 默认避免常见安全坑：未知 verification status 会归一化为 unverified，避免失败开放
- 文档明确指出 sameSite、redirect URI、X-Forwarded-For、绑定地址等容易踩坑的问题
- 支持无需传统账号系统的应用设计：Keslr 私有网络内可根据来源地址识别成员
- OIDC sub 与网络身份 userId 使用同一 UUID，方便后续从无登录模式平滑迁移到登录模式
- 测试质量看起来较高：README 声称有 330 个测试，使用真实 RSA key 和真实签名验证
- MIT 许可证，便于商业和开源项目使用
- 示例 guestbook 展示了真人签名场景，适合理解产品定位
02
目标用户
- 希望为应用接入 Keslr 登录的 TypeScript / Node.js 开发者
- 使用 Express 构建 Web 服务的后端开发者
- 希望只允许已验证真人访问服务的社区、论坛、工具类产品开发者
- 需要在 Keslr 私有网络上部署服务的团队
- 想降低注册、邮箱验证、验证码和账号系统复杂度的独立开发者或小团队
- 关注真人身份、反滥用、低垃圾内容社区的产品团队
03
配置要求
- 需要 Keslr 账号，并在 developers.keslr.com 登录
- 需要申请 Keslr developer access，且申请需要审核
- 审核通过后需要创建 Keslr app，Keslr 会分配网络地址和 your-app.app.keslr.com 形式的主机名
- 需要完成 DNS 验证
- 如使用 OIDC 登录，需要注册 OIDC client，并配置 KESLR_CLIENT_ID、KESLR_CLIENT_SECRET、redirectUri、issuer 等信息
- 如使用网络身份查询，需要注册 network client，并配置 KESLR_NETWORK_CLIENT_ID、KESLR_NETWORK_CLIENT_SECRET
- OIDC client 和 network client 是两套不同凭据，不能混用
- Express session 需要配置 SESSION_SECRET
- 使用 OIDC 回调时，cookie sameSite 应为 lax，不应为 strict
- redirect URI 必须与 Keslr 后台配置逐字节完全一致，包括协议、域名、端口、路径和末尾斜杠
- 如果服务只希望 Keslr 网络可访问，必须绑定到 Keslr 分配的地址，而不是 0.0.0.0
- 生产环境中应正确配置 HTTPS、安全 Cookie、代理信任策略和网络监听地址
04
适用场景
- 使用 Keslr 作为第三方登录提供方，实现 Sign in with Keslr
- 通过 requireVerified() 限制只有已验证真人才能执行发帖、评论、提交内容等操作
- 在 Keslr 私有网络中运行仅 Keslr 成员可访问的服务
- 无需传统注册系统，通过网络来源地址识别访问者身份
- 构建低垃圾内容的留言板、论坛、内部工具、社区应用
- 将 Keslr 用户 UUID 作为本地数据库外键，统一 OIDC 登录和网络身份解析两种身份来源
- 在需要更强安全性的场景中组合网络身份和显式登录，例如 requireNetworkIdentity() + requireVerified()
05
部署与配置
- 克隆仓库：git clone https://github.com/keslr/keslr_connect.git
- 进入目录：cd keslr_connect
- 安装依赖：npm install
- 构建项目：npm run build
- 由于包尚未发布到 npm，需要通过 npm link、workspace 或 file: dependency 在自己的项目中引用 packages/auth、packages/express、packages/network
- 如果未来发布到 npm，可直接安装：npm install @keslr/auth @keslr/express @keslr/network
- 开发和验证可运行：npm test、npm run lint、npm run build
06
风险与注意事项
- 项目处于 pre-release，API 可能在 1.0 前变化，不适合对稳定性要求极高的生产系统直接依赖
- 尚未发布到 npm，安装和依赖管理需要从源码、本地 link、workspace 或 file dependency 处理，集成成本较高
- Keslr 本身是邀请制和审核制生态，开发者和最终用户都可能受到准入门槛影响
- 强依赖 Keslr 服务和网络，如果 Keslr 服务不可用、政策变化或生态规模不足，会影响业务可持续性
- 网络身份解析只能证明是哪台 Keslr 成员设备发起连接，不能证明当前操作人一定是设备所有者
- 如果错误绑定到 0.0.0.0，服务可能暴露到公网，中间件无法替代网络层访问控制
- 对国内开发者而言，Keslr 的可访问性、合规性、延迟、手机号/实名认证兼容性、中文生态支持都需要额外验证
- OIDC 与 network client 凭据分离，配置错误可能导致首次接入成本增加
- 适用场景较垂直，主要面向 Keslr 生态；如果目标用户不在 Keslr 网络内，业务价值会显著下降
2026-08-14
第17名
新收录 · github_search
