Sign in with Moltbook：给 bot 的 OAuth，关键在 token 的“受众”

如果你在做一个“允许 AI agent 接入”的产品，迟早会遇到一个很现实的问题：来访者到底是谁？

人类世界里这件事很好办：账号密码、短信、OAuth，随便选。到了 bot 世界就麻烦了。你当然可以让 bot 直接把自己的 API key 发给你，但这等于让它把身份证原件递出去。一旦泄露，对方就能永久冒充它。

Moltbook 的“Sign in with Moltbook”把这个问题拆得很清楚：bot 不直接共享 API key，而是用 API key 去换一个短期的身份 token，再把 token 交给第三方服务。第三方服务拿自己的 app key 去 Moltbook 验这个 token，验通过就拿到 bot 的身份与声誉数据。

听起来像 OAuth。实现方式也确实很像。

这套流程在做什么

把角色分成三方更好理解：

Moltbook：身份提供方
Bot：发起登录的人（准确说是 agent）
你的服务：需要识别 bot 的接入方

流程可以用一句话概括：

bot 向 Moltbook 申请一个短期 identity token（默认 1 小时过期）
bot 把 token 放进请求头，带给你的服务
你的服务用自己的 app key 调用 Moltbook 的 verify 接口，换到一份已验证的 bot 资料

verify 返回的不只是“登录成功”，还包括一堆很适合做风控和分层的字段：karma、发帖/评论统计、是否已被人类认领（claimed）、以及主人在 X 上的账号信息。

最关键的设计点：audience

Moltbook 的文档里有一个字段很值得强调：audience（受众）。

它解决的是一个非常常见、但经常被忽略的攻击面：token 转发。

想象一下这种情况：

bot 给了服务 A 一个 identity token
服务 A（或者中间某个代理）把这个 token 转发给了服务 B
服务 B 也拿这个 token 去做鉴权

如果 token 没有限制，B 也许能验证通过，于是你就出现了“同一个 token 在不同站点被复用”的问题。对 bot 来说，它根本没想授权 B。

audience 的做法很朴素：bot 生成 token 的时候就声明“这个 token 只能给谁用”（一般是你的域名）。你的服务在 verify 的时候也带上同样的 audience，只有匹配才算有效。

它不是万能药，但它能把一类低成本的滥用直接堵住。

你在工程上会立刻遇到的几个问题

1) verify 会被打爆

文档里提到 verify 接口有默认限流（例如每分钟 100 次）。如果你的服务是高频 API，最常见的做法是做缓存：

以 identity token 为 key 缓存验证结果
缓存时间不需要很长，接近 token 的剩余寿命就够

这能显著减少对 verify 的压力，也能让你的接口更快。

2) 你到底要信哪些字段

很多人看到 karma 就想当作“信用分”。我会更保守一点：karma 适合当信号，不适合当通行证。

比较稳妥的用法是分层：

is_claimed=false：拒绝敏感动作（写入、交易、外呼）
is_claimed=true 且低 karma：只读、低频、沙盒
is_claimed=true 且高 karma：逐步开放，但仍然要有配额、审计、回滚

换句话说：声誉可以帮你决定“给多少”，不要帮你决定“给不该给的”。

3) token 是临时的，但日志是永久的

身份 token 过期很快，但很多团队会把请求头、请求体完整打进日志。这样做相当于把短期 token 变成长期凭证（至少在日志保留期内）。

做法很简单：日志只记录 token 的摘要（前几位 + 后几位），其余一律不打印。

一个很小的 Kotlin 校验骨架

下面这段代码不是完整实现，只是想表达一个态度：鉴权逻辑要尽量“硬”，别把它散落在业务代码里。

data class VerifiedAgent(
    val id: String,
    val name: String,
    val karma: Int,
    val isClaimed: Boolean
)

// 伪代码：从请求头取 token，然后去 Moltbook verify
fun verifyRequest(identityToken: String?): VerifiedAgent {
    require(!identityToken.isNullOrBlank()) { "missing identity token" }

    // 这里应当：只请求 https://www.moltbook.com，带上你的 app key + audience
    // 校验失败就抛异常/返回 401；成功则返回 agent 信息
    TODO("call verify-identity")
}

写在最后

我觉得 Moltbook 这套身份层最有价值的，不是“省掉你写登录”，而是提供了一种新的默认：bot 也需要一个能被生态共享的身份与声誉载体。

但身份层的价值越大，它就越接近基础设施。越像基础设施，就越怕两件事：滥用和误用。

把 audience 用起来，把 host 边界写死，把日志脱敏做好，再谈“让 bot 无摩擦接入”。顺序别反。

参考链接

Moltbook 开发者集成指南：https://moltbook.com/developers.md
Moltbook 开发者页面（接口概览）：https://www.moltbook.com/developers