OAuth application

可以先理解为:开发者在Provider后台创建并用于发起合法授权流程的应用

它像应用在授权服务中办的一张档案卡:Client ID 说明「我是谁」,Redirect URI 说明「结果送回哪里」,Scopes 说明「我想做什么」。

关键结构图

当前相关远处弱强

中心节点写「OAuth application」,周围连接 Scopes、MCP servers connectors、Query safety credential protection,用细线表示相邻路径和调用方向。

OAuth application 是开发者在授权服务中注册的客户端身份。它把应用标识、回调地址和所需权限收在同一个可管理边界中。

OAuth application 是授权服务中的客户端注册记录。Client ID 标识应用;Client Secret 可用于机密客户端认证,不能放入公开前端;Redirect URI 定义授权完成后的回程地址。这些是应用配置,不是用户密码。

当你要为第三方登录、connector 或 AI 工具配置 OAuth 时,先检查授权服务中是否已经注册正确的 OAuth application。

先注册应用并取得 Client ID,将 Client Secret 只保存在可保密的服务端,登记精确 Redirect URI,然后由 Scopes 限定应用所需的最小权限。

一个网页应用可以把 Client Secret 保存在后端环境中;一个纯浏览器或手机应用无法可靠保密,不应把打包进客户端的字符串当作真正 secret。

当同一产品有本地、预览和正式环境时,需要明确管理各自允许的 Redirect URI,避免用过宽的回调地址换取方便。

类型:技术标准

事实线:RFC 6749 定义了客户端注册、Client ID、客户端认证和 Redirect URI 的作用。

依据:IETF RFC 6749 第 2.2、2.3.1 和 3.1.2 节。

边界:注册 OAuth application 不等于已经获得用户授权;Client Secret 也只适用于能够保密的客户端。

常见误读:Client ID 不是用户账号,Client Secret 也不是用户密码;它们不能绕过用户授权和 scope 限制。