认证

介绍
本指南解释了在 Stacks 区块链上如何执行身份验证。
身份验证为用户提供了一种在保留对其凭证和个人信息完全控制的同时向应用程序识别自己的方式。
在您的应用上注册的用户随后可以使用支持 比特币名称系统 的任何其他应用进行身份验证,反之亦然。
web2 与 web3 身份验证的差异
Web2 通常使用用户名和密码对用户进行身份验证,并在数据库中存储密码的哈希版本。相比之下,Web3 更注重数据所有权,使用户掌控他们的信息,包括身份验证。在比特币和 Stacks 中,使用密码学生成私钥、公钥和地址。Stacks 帐户使用由 24 个助记词短语派生的私钥。该密钥有助于生成公钥,但私钥仍然是主要的安全因素,应予以保护。在像 StackingDAO 这样的应用中,钱包应用通过发送用户的地址、公钥和签名来进行身份验证,以在不暴露私钥的情况下验证私钥所有权。该过程允许使用相同的钱包和地址登录支持 Stacks 身份验证的应用。
工作原理
Stacks 的身份验证流程类似于集中式登录服务(例如 OAuth)使用的典型客户端—服务器流程。然而,对于 Stacks,身份验证流程完全在客户端进行。
此处的说明旨在让您了解该过程的工作方式,但大部分功能由钱包和您使用的 JS 库处理。
应用程序和验证器,例如 Leather 钱包,在身份验证流程中通过来回传递两个令牌进行通信。发起请求的应用向验证器发送一个 authRequest 令牌。用户批准身份验证后,验证器会向应用响应一个 authResponse 令牌。
这些令牌基于 JSON Web Token (JWT) 标准,并额外支持 secp256k1 曲线(该曲线被比特币和许多其他加密货币使用)。它们通过 URL 查询字符串传递。
当用户选择对某个应用进行身份验证时,应用会通过带有同名参数的 URL 查询字符串将 authRequest 令牌发送给验证器。
当验证器收到请求时,它会使用临时传输密钥为该应用生成一个 authResponse 令牌。临时传输密钥仅用于该应用的特定实例,在本例中用于对 authRequest.
进行签名。应用在请求生成期间存储临时传输密钥。传输密钥的公钥部分包含在 authRequest 令牌的 public_keys 字段中。验证器使用该公钥部分对应用私钥进行加密,并通过 authResponse.
将其返回。验证器从用户的身份地址私钥和应用的域名生成应用私钥。应用私钥具有三项功能:
它用于创建凭据,使应用能够访问用户 Gaia hub 中的存储桶
这允许应用访问用户在其 Gaia hub 中的应用特定存储。
它用于对存储在用户 Gaia 存储中的应用文件进行端到端加密
该密钥用于加密文件,以便只有具有派生密钥的应用能够解密这些文件。
它作为应用可用于执行其他加密功能的加密秘密
应用可以使用此确定性秘密执行与用户身份和域相关的额外加密操作。
最后,应用私钥是确定性的,这意味着对于给定的 Stacks 地址和域,总是会生成相同的私钥。
密钥对
Stacks 身份验证广泛使用公钥密码学,尤其是使用带有 secp256k1 曲线的 ECDSA。
以下各节描述了使用的三对公私钥,包括它们如何生成、在哪里使用以及私钥向谁披露。
传输私钥
传输私钥是一个临时密钥,用于加密在身份验证过程中需要从验证器传递给应用的机密信息。它由应用在身份验证请求开始时随机生成。
与传输私钥对应的公钥以单元素数组的形式存储在身份验证请求令牌的 public_keys 键中。验证器使用该公钥加密诸如应用私钥之类的秘密数据,并在用户登录应用时将其发送回应用。传输私钥对应用的身份验证请求进行签名。
身份地址私钥
身份地址私钥由用户的密钥短语派生,是用户选择用于登录应用的 Stacks 用户名的私钥。它是用户拥有的秘密,且永远不会离开用户实例中的验证器。
该私钥为应用的身份验证响应令牌签名,以表明用户批准登录该应用。
应用私钥
应用私钥是一个特定于应用的私钥,使用用户的身份地址私钥并以 domain_name 作为输入生成。
应用私钥在每次身份验证时由验证器使用传输公钥对其进行加密并安全地与应用共享。由于传输密钥仅存储在客户端侧,这可以防止中间人攻击,例如服务器或互联网提供商可能窥探应用私钥的情况。
最后更新于
这有帮助吗?