在我们掌握了DID的基础知识（还没有掌握DID基础知识？请先阅读我之前的关于DID的文章），构建DID平台的时候，DID的常见应用就是基于DID实现第三方平台的登录。接下来，我们假设已经构建了一个基础的DID平台，用长安链实现了DID文档的链上管理，并提供了DID钱包托管用户的公私钥和VC证书，建设全新的第三方系统实现DID登录。
前置条件
我们已经建设了一个DID分布式身份的应用，为每个用户颁发了DID，对应的DID文档也上到了一条区块链（比如长安链）上。每个用户有自己的DID钱包（可以是浏览器插件钱包，也可以是手机APP钱包），在DID钱包中保存了用户的公私钥、DID和各种颁发的证书VC信息。
场景1：DID登录
需求
现在我们要建一个新的服务系统，并希望使用DID进行登录，类似于网上的使用Google账号登录或者微信扫码登录这样的OAuth登录，只要是在长安链上有颁发了身份的用户，都可以通过其DID钱包进行登录。
技术实现
以下是一个简化版的DID钱包登录流程，并以浏览器插件钱包为例：
1.用户在第三方应用上发起登录请求。
2.第三方应用后端生成一个随机数（nonce）并发送给钱包浏览器插件。
3.钱包浏览器插件使用用户的DID私钥对随机数进行签名，并将签名和用户的DID一起发送给第三方应用后端。
4.第三方应用后端将签名和DID发送给DID合约进行验证。
5.DID合约查询区块链上的DID文档，获取DID的公钥，并使用公钥验证签名。如果验证成功，返回用户的身份信息给第三方应用后端。
6.第三方应用后端根据返回的身份信息，完成用户的登录或注册操作，并返回登录结果给用户。
以下是对应的时序图：
场景2. 基于VC/VP的DID登录
需求
有些应用并不是任何获得了DID身份的用户就能够登录的，比给企业T做一个员工福利网站，只有企业T的员工才能正常登录。所以我们需要基于VC（可验证凭证）和VP（可验证表示）的DID登录。
技术实现
前置条件是企业T已经作为颁证机构，给自己企业的员工都颁发了员工卡VC，员工在登录网站的时候，需要出示该员工卡VC，验证VC通过才能正常登录。流程如下：
- 用户在第三方应用上发起登录请求。
- 第三方应用后端生成一个随机数（nonce）和要求的VC类型，发送给钱包浏览器插件。
- 钱包浏览器插件根据要求的VC类型，从用户的DID钱包中选择相应的VC，并生成一个VP（包含DID、VC和nonce）。
- 用户使用DID私钥对VP进行签名，并将签名的VP发送给第三方应用后端。
- 第三方应用后端将签名的VP发送给DID合约，通过查询合约的方式进行验证。
- DID合约首先验证VP的签名。如果签名验证通过，继续检查VP中的VC。这包括验证VC的签名、检查VC的颁发者和过期时间等。
- 如果VP和VC的验证都成功，DID合约将返回用户的身份信息给第三方应用后端。
- 第三方应用后端根据返回的身份信息，完成用户的登录或注册操作，并返回登录结果给用户。
总结
基于DID进行登录相对于互联网的OAuth登录有以下优势：
- 更高的安全性：在DID登录中，用户的私钥始终保存在钱包中，不会泄露给其他参与方，减少了中心化存储的风险。而在OAuth登录中，用户的访问令牌和刷新令牌需要在第三方应用和授权服务器之间传递，增加了被攻击者截获的风险。
- 更好的隐私保护：DID登录允许用户选择性地披露自己的身份信息，甚至是基于零知识证明保护隐私，而不是像OAuth登录那样，将用户的信息都暴露给第三方应用。
- 去中心化：DID是基于区块链技术的去中心化身份解决方案，不依赖于任何中心化的身份提供商。这意味着用户可以拥有并控制自己的数字身份，而无需依赖于第三方服务。而OAuth登录依赖于授权服务器，如Google或Facebook，这些服务可能会受到审查、关闭或遭受攻击。
- 更简洁的用户体验：DID登录简化了身份验证过程，用户只需要使用钱包生成、管理DID和签名，无需记住多个用户名和密码。而在OAuth登录中，用户需要在不同的授权服务器上创建和管理账户，可能导致多个用户名和密码的混淆。
- 更易于实现自主身份：通过使用DID，用户可以建立自主身份（Self-Sovereign Identity，SSI），这是一种用户拥有并控制自己身份信息的模型。在这种模型中，用户可以将身份信息存储在自己控制的设备上，而不是依赖于中心化的身份提供商。这有助于实现更高程度的隐私保护和数据所有权。而在OAuth登录中，用户的身份信息通常由授权服务器管理，用户无法完全控制自己的数据。