最适合智能体的身份认证技术:对比OpenID Connect、API keys、did:wba
最适合智能体的身份认证技术:对比OpenID Connect、API keys、did:wba
智能体需要新的身份认证技术
智能体对身份认证技术提出了新的需求,其中最重要的一个就是互联互通,特别是让任意两个智能体都能够互联互通。
其中的原理很简单:AI必须具备获得完整上下文信息的能力,具备调用所有工具的能力,才能够作出正确的决策,采取合适的行动。现在很多厂商试图使用Computer Use方案解决这个问题。
但是我们认为这不是AI与互联网交互最高效的方式。这是让AI模仿人的方式访问互联网,AI应该用它最擅长的方式(API或通信协议)与数字世界交互。
这就涉及一个互联互通的问题:在智能体使用API或协议,与互联网或者其他智能体交互的时候,如何进行身份验证?特别进行跨平台的身份验证,以让任何智能体之间都能够进行连接。
当前主流跨平台身份认证技术
我们在互联网上的身份账号,很多时候是不能跨平台使用的。比如你的微信账号,在钉钉系统中是无法识别的,反之亦然。
不过现在互联网也有很多跨平台的身份认证技术,比如我们常见的SSO(单点登录),你可以用你的谷歌账户登录很多网站。还有API keys,比如你可以使用OpenAI给你的key,访问OpenAI的API。下面我来简单的介绍下这两种技术,看看是否适合智能体的身份认证。
OpenID Connect(OIDC)
OpenID Connect (OIDC) 是一种基于 OAuth 2.0 构建的身份验证协议,它允许客户端应用程序验证用户身份,并获取用户的基本信息(如姓名、邮箱)。OIDC 在 OAuth 2.0 的基础上增加了标准化的身份层,使其更适合于登录和单点登录(SSO)场景。
OpenID Connect 官方规范。
下面我们以使用谷歌账号登录三方网站为例来介绍下OIDC的流程。谷歌OIDC官方文档地址。。
使用谷歌账号登录三方网站包括两部分,前置流程和Oauth2.0流程:
-
前置流程 -
注册谷歌平台账号 -
创建项目/应用 -
配置项目/应用,包括重定向URI -
获取OAuth 2.0的client id和client secret
-
-
Oauth2.0流程(以授权码流程为例) -
获取授权码 -
使用授权码获取access token和id token,id token中包含用户信息 -
使用access token和id token访问获取用户的详细信息(可选)。在OpenID Connect流程中,用户的详细信息可以认为是一种受保护的资源。
-
OpenID Connect的优点是:
-
能够简化用户的身份验证流程 -
使用非常广泛,相关基础设施也比较完善。 -
安全性较高
站在智能体互联互通的场景看,OpenID Connect有几个不足:
-
OpenID Connect本质上是让三方应用能够使用身份服务器(比如谷歌)对用户进行身份验证。两个三方应用之间无法使用身份服务器实现他们之间的身份验证。 -
OpenID Connect是一个中心化的方案,用户使用的时候需要去身份服务器进行注册等操作,前置操作流程复杂。 -
流程交互复杂,需要多次交互。
API keys
API Keys(API 密钥)是用于验证应用程序或用户访问应用程序编程接口(API)的简单凭证。它是一种字符串形式的身份标识符,通常由随机生成的字母和数字组成,类似于密码的功能。它可以用于身份验证、访问控制、使用监控等场景。
使用API Keys验证用户身份的流程:
-
前置流程 -
去平台注册账号 -
获取API Keys
-
-
API keys验证流程 -
在类似https的安全协议请求头中添加API keys -
服务端验证客户端的API keys
-
API keys的优点是:
-
简单,易于实现,交互少 -
支持跨平台身份认证,两个应用只要相互有对方API keys,就可以验证身份 -
广泛用于API服务当中,比如OpenAI、国内的模型API等,大部分使用API keys进行身份验证。
站在智能体互联互通的场景看,API keys有几个不足:
-
安全性较低。有很多使用API keys做身份验证的MCP server,往往要求用户将API keys写在配置文件中,存在泄漏风险。
-
仍然需要前置流程,需要用户登录注册等操作。
基于W3C DID的身份认证技术:did:wba
W3C DID是什么
W3C DID(Decentralized Identifier,DID)是一种新的去中心化标识符标准,旨在解决传统中心化身份管理系统的依赖性。它与2022年发布为推荐标准。规范地址:https://www.w3.org/TR/did-core/
目前已经有很多应用在使用W3C DID规范,比较知名的是最近比较火的bluesky,一个去中心化的推特应用。
did:wba是什么
did:wba是AgentNetworkProtocol(ANP)定义的一个did方法规范。它基于web基础设施,实现了去中心化的身份认证,专门针对agent之间的身份认证而设计。规范地址:did:wba方法规范。
与did:wba非常类似的业务是email:各个平台有自己的账号,但是不同平台之间能够非常简单的进行身份认证与通信。同时他们都基于web基础设施,能够支持大规模用户的同时,实现去中心化。
假设智能体A要订阅并调用智能体B的服务,身份验证以及请求流程如下:
-
前置流程 -
智能体A要订阅智能体B的服务,首先调用智能体B的服务订阅接口,并且携带智能体A的DID和签名,让B知道是智能体A发起的订阅。
-
-
身份验证流程 -
智能体A在首次http请求中,在http头中携带A的DID和签名。 -
智能体B收到http请求后,从http头中提取A的DID和签名,然后根据A的DID,去A的DID server获取A的DID文档。 -
智能体B获取到A的DID文档后,使用A的DID文档中的公钥对A的签名进行验证。 -
验证通过后,智能体B处理A的业务请求,返回业务数据的同时,返回access token。 -
智能体A在后续请求中携带access token,智能体B通过对access token的验证,完成对A的身份认证。
-
did:wba身份验证方案的优点:
-
安全性高 -
充分利用web基础设施,能够支持大规模用户,可实施性强 -
去中心化设计,能够让任意两个智能体体或应用之间进行身份认证 -
前置流程简单,无需用户人工注册,无需用户人工登录配置 -
身份验证流程简单,不增加交互次数
当然,did:wba也有一些缺点,最大的缺点是作为一个2022年发布的规范,基础设施不够完善,应用范围相对比较有限。不过我们也能够看到像bluesky这样的明星案例。
对比:did:wba vs OpenID Connect / API keys
站在智能体身份验证的角度,对比did:wba和OpenID Connect、API keys:
-
安全性:did:wba和OpenID Connect具备同等的安全性,都比API keys的安全性高。 -
复杂度:OpenID Connect的复杂度最高,API keys的复杂度最低,did:wba的复杂度介于两者之间。 -
交互次数:did:wba和API keys的交互最少,OpenID connect的交互最多. -
前置流程:did:wba能够做到无需用户人工处理,OpenID connect和API keys都需要用户人工处理。 -
去中心化:did:wba和API keys都可以做到让任意智能体或应用互相通信。OpenID connect无法做到 -
应用范围:OpenID Connect和API keys应用范围都比较广泛,did:wba则是比较新的规范,应用范围有限。
总体对比如下:
对比项 | did:wba | OpenID Connect | API keys |
---|---|---|---|
安全性 | 高 | 高 | 中等 |
复杂度 | 中等 | 高 | 低 |
交互次数 | 少 | 多 | 少 |
前置流程 | 简单,无需人工 | 复杂,需要人工 | 中等,需要人工 |
去中心化 | 是 | 否 | 是 |
应用范围 | 有限 | 广泛 | 广泛 |
从上面的对比我们可以看到,did:wba不但能够支持所有的智能体互联互通,并且具备OpenID Connect的安全性以及API keys的简单性,同时也支持大规模用户使用。综合来看,did:wba是最适合智能体之间进行身份认证的方案。
当然,OpenID Connect和API keys仍然有他们自己的作用。比如,智能体在和原有互联网系统对接的时候,可能仍然需要使用OpenID Connect和API keys。
本文由 mdnice 多平台发布