Erik 张使用 NEP-33 完成 Neo 身份验证三重奏

Neo 联合创始人 Erik Zhang 发布了 NEP-33，这是他两周内提出的第三个 Neo 增强提案。该标准定义了一种基于 URI 的传输机制，允许本机应用程序调用钱包应用程序进行身份验证，从而完成一个三层堆栈，标准化用户使用 Neo 钱包登录的方式。

NEP-33 遵循 NEP-20（建立了加密身份验证规则）和 NEP-21（为 dApp 与钱包提供商通信定义了统一接口）。在这两个标准处理身份验证逻辑和钱包功能的地方，NEP-33 解决了入口点：一个应用程序如何将身份验证请求传递给钱包并接收结果。

这可以实现什么

在 NEP-33 之前，移动或桌面应用程序没有调用 Neo 钱包进行身份验证的标准化方法。

每个钱包和应用程序都实现了自己的调用和回调格式，从而产生了碎片。 NEP-33 引入了 neoauth://，这是一种自定义 URI 方案，可为本机应用程序提供通用的“使用 Neo 登录”入口点。操作系统将请求路由到兼容的钱包，该钱包通过回调 URI 返回结果。

基于 Neo 构建的开发人员现在可以集成钱包身份验证，而无需为每个提供商编写特定于钱包的代码。

此外，NEP-33 的设计考虑了向前兼容性。在对该提案的 GitHub Pull 请求的评论中，Zhang 解决了一个关于不同 Neo 网络版本是否应该存在单独的 URI 方案的问题：

由于N3和N4的地址格式相同，因此无需区分。而这只是一个传输层协议。 NEP-20中有一个网络协商过程。

该设计使 neoauth:// 方案与网络无关，并在 NEP-20 层处理网络选择。

NEP-33 的工作原理

应用程序使用 neoauth:// 方案构建请求 URI，嵌入 URL 编码的 NEP-20 质询负载和 dApp 标识符。操作系统将其路由到已注册的钱包应用程序，该应用程序可以是通用目标（将钱包选择委托给操作系统或用户）或特定的钱包实现。

钱包解码并验证有效负载，向用户显示身份验证详细信息（包括请求域），并需要明确批准。如果用户批准，钱包会生成 NEP-20 响应负载，并使用 dapp:// 方案通过回调 URI 返回它。如果用户拒绝请求或发生错误，钱包将通过相同的回调机制返回结构化错误响应。

所有身份验证验证都遵循 NEP-20 的加密规则，这意味着请求应用程序必须验证返回的签名，而不是信任回调 URI 本身作为身份验证证明。

NEP-33 并没有重新定义身份验证是什么或其功能，而是将该功能引入 dApp 和钱包之间的交互流程中。

安全模型

由于自定义 URI 方案不能保证机密性或应用程序身份，因此 NEP-33 的安全性完全依赖于 NEP-20 签名验证。

该标准要求钱包清楚地显示请求域以防止网络钓鱼，强制执行独特的一次性随机数，建议在五分钟内到期以防止重放攻击，并在生成任何签名之前强制要求用户明确批准。

NEP-33 专为一次性身份验证流程而设计。它不应用于交易签名、资产转移、智能合约调用或基于会话的授权。

完整公告可在以下链接找到：https://x.com/erikzhang/status/2042931327943741471