先明确认证对象与适用范围
“区块链认证”可能指账户控制权验证、操作授权或数据核验。本文讨论以太坊账户及签名验证，不涵盖所有链的认证机制，也不将其等同于实名审核。适用前提是：业务需要确认某条消息是否获得指定账户授权，并能明确待验证的内容。
以太坊账户文档区分外部账户与合约账户：前者由私钥控制，后者由代码逻辑控制。钱包是与账户交互的工具，因此连接钱包与完成签名认证属于不同环节。
第一步：确定账户与验证规则
认证前需要明确预期账户和相应验证规则。对于采用常规私钥签名的外部账户，可以通过签名恢复地址，再与预期地址比较。对于合约账户，需要使用其支持的签名验证机制，不能假定它拥有对应私钥。
OpenZeppelin密码学工具文档介绍了ECDSA验签、兼容ERC-1271合约签名的SignatureChecker，以及处理结构化签名数据的EIP712工具。这些机制分别解决不同验证需求，选用条件取决于账户与消息类型。
第二步：明确签名内容及使用边界
签名方与验证方必须对消息内容、编码及哈希方式达成一致，否则无法可靠地验证同一份授权。涉及结构化业务字段时，可以采用EIP-712，但具体字段仍需由应用定义。
当授权限定于某条链或某个验证合约时，相应上下文需要纳入验证范围。域分隔有助于区分签名的使用环境，但不会自动补齐业务权限规则。
第三步：验签并检查重复使用
验签通过后，还需判断消息是否符合本次业务要求。对于只允许执行一次的授权，应设置并验证nonce或记录消息摘要的使用状态。不能仅以签名字节不同来判断是否属于新授权。
链上交易的nonce与应用中的消息防重放需要分别理解。普通消息签名不会自动继承交易的防重放效果；同一条有效签名能否再次使用，取决于应用是否实施了相应限制。
常见问题：有效签名能证明什么
签名通过是否等于身份真实？不能直接等同。它支持判断消息是否符合该账户的签名或授权规则；若业务需要对应真实个人、组织或资格，还需要额外的身份关联证据。
认证是否必须上链？单纯验证外部账户的消息签名可以在链下完成。若还要执行合约操作或变更链上状态，则涉及交易处理。合约账户的签名有效性还可能依赖合约状态，因此验证时需要明确所依据的链上环境。