核心概念
认证 vs 授权
虽然这两个术语经常互换使用,但它们代表了不同的安全概念: 在 LangSmith 中,认证由你的@auth.authenticate 处理器处理,授权由你的 @auth.on 处理器处理。
默认安全模型
LangSmith 提供不同的安全默认值:LangSmith
- 默认使用 LangSmith API 密钥
- 需要在
x-api-key头中提供有效的 API 密钥 - 可以使用你的认证处理器进行自定义
自定义认证
LangSmith 的所有计划都支持自定义认证。
自托管
- 没有默认认证
- 完全灵活地实现你的安全模型
- 你控制认证和授权的所有方面
系统架构
典型的认证设置涉及三个主要组件:- 认证提供者(身份提供者/IdP)
- 一个管理用户身份和凭证的专用服务
- 处理用户注册、登录、密码重置等
- 在成功认证后颁发令牌(JWT、会话令牌等)
- 示例:Auth0、Supabase Auth、Okta 或你自己的认证服务器
- 代理服务器(资源服务器)
- 你的代理或 LangGraph 应用程序,包含业务逻辑和受保护资源
- 与认证提供者验证令牌
- 基于用户身份和权限强制执行访问控制
- 不直接存储用户凭证
- 客户端应用程序(前端)
- Web 应用、移动应用或 API 客户端
- 收集时效性用户凭证并发送给认证提供者
- 从认证提供者接收令牌
- 在向代理服务器发出的请求中包含这些令牌
@auth.authenticate 处理器处理步骤 4-6,而你的 @auth.on 处理器实现步骤 7。
认证
LangGraph 中的认证作为每个请求的中间件运行。你的@auth.authenticate 处理器接收请求信息,并应:
- 通过
ctx.user提供给你的授权处理器 - 在你的应用程序中通过
config["configuration"]["langgraph_auth_user"]访问
代理认证
自定义认证允许委托访问。你在@auth.authenticate 中返回的值会添加到运行上下文中,为代理提供用户范围的凭证,使它们能够代表用户访问资源。
认证后,平台会创建一个特殊的配置对象,通过可配置上下文传递给你的图和所有节点。
此对象包含有关当前用户的信息,包括你从 @auth.authenticate 处理器返回的任何自定义字段。
要使代理能够代表用户操作,请使用自定义认证中间件。这将允许代理代表用户与外部系统(如 MCP 服务器、外部数据库甚至其他代理)进行交互。
更多信息,请参阅使用自定义认证指南。
使用 MCP 的代理认证
有关如何向 MCP 服务器认证代理的信息,请参阅 MCP 概念指南。授权
认证后,LangGraph 调用你的@auth.on 处理器来控制对特定资源(例如,线程、助手、定时任务)的访问。这些处理器可以:
- 通过直接修改
value["metadata"]字典,在资源创建时添加要保存的元数据。有关每个操作的值可以采用的类型列表,请参阅支持的操作表。 - 在搜索/列表或读取操作期间,通过返回过滤器字典按元数据过滤资源。
- 如果访问被拒绝,则引发 HTTP 异常。
@auth.on 处理器。如果你想根据资源和操作进行不同的控制,可以使用特定于资源的处理器。有关支持访问控制的资源的完整列表,请参阅支持的资源部分。
特定于资源的处理器
你可以通过将资源和操作名称与@auth.on 装饰器链接在一起来注册特定资源和操作的处理器。
当发出请求时,将调用与该资源和操作匹配的最具体的处理器。以下是注册特定资源和操作处理器的示例。对于以下设置:
- 认证用户可以创建线程、读取线程以及在线程上创建运行
- 只有具有 “assistants:create” 权限的用户才允许创建新的助手
- 所有其他端点(例如,删除助手、定时任务、存储)对所有用户都禁用。
thread 的请求将匹配 on_thread_create 处理器,但不会匹配 reject_unhandled_requests 处理器。然而,update 线程的请求将由全局处理器处理,因为我们没有针对该资源和操作的更具体的处理器。
过滤器操作
授权处理器可以返回None、布尔值或过滤器字典。
None和True表示 “授权访问所有下属资源”False表示 “拒绝访问所有下属资源(引发 403 异常)”- 元数据过滤器字典将限制对资源的访问
- 默认值是精确匹配或下面的 “$eq” 的简写。例如,
{"owner": user_id}将仅包含元数据中包含{"owner": user_id}的资源 $eq:精确匹配(例如,{"owner": {"$eq": user_id}})- 这等同于上面的简写{"owner": user_id}$contains:列表成员资格(例如,{"allowed_users": {"$contains": user_id}})或列表包含(例如,{"allowed_users": {"$contains": [user_id_1, user_id_2]}})。这里的值必须分别是列表的元素或列表元素的子集。存储资源中的元数据必须是列表/容器类型。
AND 过滤器处理。例如,{"owner": org_id, "allowed_users": {"$contains": user_id}} 将仅匹配元数据中 “owner” 为 org_id 且 “allowed_users” 列表包含 user_id 的资源。
有关更多信息,请参阅参考 Auth(Auth)。
常见访问模式
以下是一些典型的授权模式:单所有者资源
这种常见模式允许你将所有线程、助手、定时任务和运行限定到单个用户。它适用于常见的单用户用例,如常规聊天机器人风格的应用程序。基于权限的访问
这种模式允许你基于权限控制访问。如果你想让某些角色对资源具有更广泛或更受限的访问权限,这很有用。支持的资源
LangGraph 提供三个级别的授权处理器,从最通用到最具体:- 全局处理器(
@auth.on):匹配所有资源和操作 - 资源处理器(例如,
@auth.on.threads、@auth.on.assistants、@auth.on.crons):匹配特定资源的所有操作 - 操作处理器(例如,
@auth.on.threads.create、@auth.on.threads.read):匹配特定资源上的特定操作
@auth.on.threads.create 优先于 @auth.on.threads。
如果注册了更具体的处理器,则不会为该资源和操作调用更通用的处理器。
支持的操作和类型
以下是所有支持的操作处理器:“关于运行”运行的访问控制范围限定为其父线程。这意味着权限通常从线程继承,反映了数据模型的对话性质。除创建外的所有运行操作(读取、列表)都由线程的处理器控制。
有一个特定的
create_run 处理器用于创建新运行,因为它有更多参数,你可以在处理器中查看。后续步骤
有关实现细节:将这些文档连接到 Claude、VSCode 等,通过 MCP 获取实时答案。

