Skip to main content

Wallet Social Auth MFA 要看下SDK源码

web3auth 原理 ⚡️​

alt text

这张图展示了 Web3Auth 的工作原理，特别是关于私钥管理和分布的机制。图中显示了私钥可以通过多个渠道进行分割和存储，以提高安全性和便捷性。

  1. Private Key（私钥）：中心节点，代表用户的私钥。
  2. Device（设备）：私钥的一部分可以存储在用户的设备上。
  3. Backup/Security Question（备份/安全问题）：私钥的一部分可以通过备份或安全问题进行恢复。
  4. Google, Twitter, etc.（Google, Twitter 等）：私钥的一部分可以通过社交媒体账户进行管理。
  5. 2/n 和 5/9：这是门限签名方案的表示，意味着需要至少 n 个中的 2 个或 9 个中的 5 个部分才能重构和使用私钥。
  6. Device 2 和 Device 3：额外的设备用于存储私钥的其他部分。

Wallet 使用 Social Auth MFA ⚡️​

图中还列出了多个支持 Web3Auth 的合作伙伴和平台，如 Binance、Ethereum、Torus Network 等。

是的，正如你所理解的那样，当你的项目使用 Discord OAuth2 授权登录时，如果用户在其 Discord 账户中启用了多因素认证（MFA），他们在登录 Discord 时会被要求完成 MFA。这是由 Discord 平台处理的，与你的应用程序的 OAuth2 流程无关。

流程概述​

  1. 用户点击登录链接：

    • 用户点击你应用中的“Login with Discord”链接，这会将他们重定向到 Discord 的 OAuth2 授权页面。

  2. 用户登录 Discord：

    • 如果用户尚未登录 Discord，他们会被要求输入其 Discord 账户的用户名和密码。
    • 如果用户启用了 MFA，他们会在登录过程中被要求输入额外的验证信息（例如，通过身份验证应用生成的一次性密码）。

  3. 用户授权应用：

    • 一旦用户成功登录并完成 MFA，他们会看到一个授权页面，询问他们是否允许你的应用访问其 Discord 信息。
    • 用户点击“授权”按钮。

  4. 获取授权码并交换为访问令牌：

    • Discord 将用户重定向回你的应用，并附带一个授权码。
    • 你的应用使用授权码向 Discord 请求访问令牌。

  5. 使用访问令牌获取用户信息：

    • 你的应用使用访问令牌向 Discord API 请求用户信息，并在应用中处理这些信息（例如，登录用户）。

代码示例回顾​

前面的代码示例展示了如何实现上述流程。尽管代码中没有直接处理 MFA，但 MFA 是在用户登录 Discord 时由 Discord 平台处理的。

示例代码​

from flask import Flask, redirect, request, session, url_for
import requests
import os

app = Flask(__name__)
app.secret_key = os.urandom(24)

# Discord OAuth2 credentials
CLIENT_ID = 'YOUR_DISCORD_CLIENT_ID'
CLIENT_SECRET = 'YOUR_DISCORD_CLIENT_SECRET'
REDIRECT_URI = 'http://localhost:5000/callback'
DISCORD_OAUTH_URL = 'https://discord.com/api/oauth2/authorize'
DISCORD_TOKEN_URL = 'https://discord.com/api/oauth2/token'
DISCORD_API_URL = 'https://discord.com/api/v6'

# Scope for Discord OAuth2
OAUTH_SCOPE = 'identify email'

@app.route('/')
def home():
    return '<a href="/login">Login with Discord</a>'

@app.route('/login')
def login():
    # Step 1: Redirect user to Discord's OAuth2 authorization page
    discord_login_url = f"{DISCORD_OAUTH_URL}?client_id={CLIENT_ID}&redirect_uri={REDIRECT_URI}&response_type=code&scope={OAUTH_SCOPE}"
    return redirect(discord_login_url)

@app.route('/callback')
def callback():
    # Step 2: Exchange authorization code for access token
    code = request.args.get('code')
    data = {
        'client_id': CLIENT_ID,
        'client_secret': CLIENT_SECRET,
        'grant_type': 'authorization_code',
        'code': code,
        'redirect_uri': REDIRECT_URI,
        'scope': OAUTH_SCOPE
    }
    headers = {
        'Content-Type': 'application/x-www-form-urlencoded'
    }
    response = requests.post(DISCORD_TOKEN_URL, data=data, headers=headers)
    response_data = response.json()
    access_token = response_data['access_token']

    # Step 3: Use the access token to fetch user information from Discord
    headers = {
        'Authorization': f'Bearer {access_token}'
    }
    user_response = requests.get(f'{DISCORD_API_URL}/users/@me', headers=headers)
    user_data = user_response.json()

    # Store user information in session (or handle as needed)
    session['user'] = user_data

    return f"Logged in as {user_data['username']}#{user_data['discriminator']}"

@app.route('/logout')
def logout():
    session.pop('user', None)
    return redirect(url_for('home'))

if __name__ == '__main__':
    app.run(debug=True)

总结​

  • MFA 处理：MFA 是在用户登录 Discord 账户时由 Discord 平台处理的。如果用户启用了 MFA，他们在登录过程中会被要求完成额外的验证步骤。
  • OAuth2 授权流程：一旦用户成功登录并完成 MFA，OAuth2 授权流程继续进行，用户可以授权你的应用访问其 Discord 信息。

因此，你的项目在实现 Discord OAuth2 授权登录时不需要额外处理 MFA，只需按照标准的 OAuth2 流程进行即可。Discord 会在用户登录时处理所有必要的认证步骤，包括 MFA。

mermaid​

当然可以。我将使用 Mermaid 绘制流程图，展示用户在使用 Discord OAuth2 进行授权登录时的整个流程，包括多因素认证（MFA）的处理步骤。

以下是 Mermaid 代码：

Mermaid 图示解释​

  1. 用户点击登录链接：

    • 用户点击应用中的“Login with Discord”链接，应用将用户重定向到 Discord 的 OAuth2 授权页面。

  2. 用户登录 Discord：

    • Discord 显示登录页面，用户输入用户名和密码。
    • 如果用户启用了 MFA，Discord 会提示用户进行 MFA 验证，用户输入 MFA 代码。

  3. 用户授权应用：

    • 用户完成登录后，Discord 显示授权页面，用户点击“Authorize”按钮。

  4. 获取授权码并交换为访问令牌：

    • Discord 将用户重定向回应用，并附带授权码。
    • 应用使用授权码向 Discord 请求访问令牌。

  5. 使用访问令牌获取用户信息：

    • 应用使用访问令牌向 Discord API 请求用户信息，并在应用中处理这些信息（例如，登录用户）。

生成的流程图​

你可以将上面的 Mermaid 代码粘贴到支持 Mermaid 的工具（如 Mermaid Live Editor）中，以生成可视化的流程图。这样可以更直观地理解整个 OAuth2 授权登录的流程以及 MFA 的处理步骤。

Social login 5/9 ⚡️​

下面是对这幅图的一些解释，你帮我理解下 social login 5/9 这块

social login share into nine motions and these nine Shares are held by nine， nodes run by ecosystem stakeholders such as binance ethereum naming servers scale，we run one of the nodes etherscan ontology silica tournament，all these nine nodes hold the nine shares of the oauth share，and when the user is trying to log in we fetch 5 out of these nine reconstruct，the social login share and combine this with any of the other，two shares to reconstruct the entire private key，that's how the private key itself is not stored anywhere but it just gets split and reconstructed on the front end technically this could also be 2 by n that is there can be n number of shares

alt text

第一次使用 Discord Social login , 第二次使用 Chrome Social login ⚡️​

你的意思是说 我第一次使用 Discord Social login 时候生成了 OAuth Share，与此同时有个用户 ID, 第二次绑定 Chrome Social login 是与这个用户 ID 绑定的，因为增加了一个 Social login ,所以 OAuth Share 会重新分配，也会在我的设备上重新分配一次，这样之后，我的设备获取到新的 Device Share、Discord Social login 或者 Chrome Social login 可以获取到新的 OAuth Share

是的，你理解得很准确。让我们再详细梳理一下这个过程，以确保每个步骤都清晰明了。

初次登录（Discord Social Login）​

  1. 生成 OAuth Share：

    • 当你第一次使用 Discord 进行社交登录时，Web3Auth 会生成一个 OAuth Share，并将其分割成多个加密分享，分布式存储在多个节点上。
    • 同时，系统会在你的设备上生成一个设备分享（Device Share）。

  2. 用户 ID 创建：

    • Web3Auth 会为你创建一个唯一的用户 ID，用于标识和关联你的各种登录方式和设备。

第二次登录（Chrome Social Login）​

  1. 生成新的 OAuth Share 和 Device Share：

    • 当你第二次使用 Chrome 进行社交登录时，Web3Auth 会生成一个新的 OAuth Share，并将其分割成多个加密分享，分布式存储在多个节点上。
    • 同时，系统会在你的设备上生成一个新的设备分享（New Device Share）。

  2. 多因素验证（MFA）：

    • 为了确保安全性，系统可能会要求你进行多因素验证（例如通过电子邮件、短信或其他方式），确认你是账户的合法拥有者。

  3. 关联新 OAuth Share：

    • 一旦验证通过，系统会将新的 OAuth Share 与之前的 Discord OAuth Share 和用户 ID 关联起来。

关联机制​

  1. 用户标识：

    • Web3Auth 使用唯一的用户 ID 来关联不同的 OAuth Share 和设备分享。这个用户 ID 在初次生成 OAuth Share 时创建，并在后续授权过程中使用。

  2. 分布式节点更新：

    • 节点会更新存储的信息，以记录新的 OAuth Share 和用户 ID 的关联。

后续使用（只用 Chrome 授权）​

  1. 获取 OAuth Share：

    • 当你在后续使用中只通过 Chrome 进行授权时，系统会从分布式节点中获取必要的加密分享。

  2. 重建和签名：

    • 通过 Chrome 上的设备分享和从节点获取的加密分享，系统可以在前端重建初次生成的 Discord OAuth Share，满足门限签名条件，完成签名操作。

安全性考虑​

  • 多因素验证：在关联新的 OAuth Share 时，通过多因素验证确保只有合法用户可以关联新的 OAuth Share。
  • 分布式存储和加密：加密分享的分布式存储确保了即使部分节点被攻破，OAuth Share 仍然是安全的。

总结​

通过多因素验证和分布式节点管理，Web3Auth 能够在不同的社交登录平台（如 Discord 和 Chrome）之间关联和管理用户的 OAuth Share。初次使用 Discord 生成的 OAuth Share 可以通过用户 ID 和新的 OAuth Share 的关联机制，在后续使用中仅通过 Chrome 授权也能获取和使用初次生成的 OAuth Share，从而实现无缝的多平台访问体验。

所以，简而言之，初次生成的 OAuth Share 和用户 ID 会在你增加新的社交登录方式（如 Chrome）时进行重新分配和关联。之后，你的设备上的新 Device Share、Discord Social login 或者 Chrome Social login 都可以获取到更新后的 OAuth Share。

Social login 与 用户 合约关联 ⚡️​

在 Web3Auth 中，维护链上数据与用户的映射关系是通过加密技术和去中心化存储机制来实现的。以下是详细的步骤和方法：

1. 用户身份管理​

  • 用户 ID：在用户首次登录时，Web3Auth 会生成一个唯一的用户 ID。这是用户的身份标识，用于关联各种社交登录方式和链上数据。
  • 加密分享：用户的 OAuth Share 会被分割成多个加密分享，并分布式存储在多个节点上。这些分享用于重建用户的身份信息。

2. 链上数据映射​

  • 智能合约：在区块链上，智能合约可以用来存储和管理用户的链上数据。这些数据可以包括用户的余额、交易记录、数字资产等。
  • 用户 ID 映射：智能合约可以将链上数据与 Web3Auth 生成的用户 ID 进行映射。这样，每个用户 ID 可以对应到特定的链上数据。

3. 数据访问和验证​

  • 多因素验证（MFA）：在用户访问链上数据时，Web3Auth 可能会要求进行多因素验证，以确保用户身份的合法性。
  • 重建 OAuth Share：用户通过社交登录（如 Discord 或 Chrome）和设备分享，可以重建初次生成的 OAuth Share，满足门限签名条件，完成数据访问和操作。

4. 去中心化存储和管理​

  • 分布式节点：Web3Auth 使用分布式节点来存储和管理用户的加密分享。这些节点共同参与存储和重建用户的 OAuth Share。
  • 加密技术：加密分享的分布式存储确保了即使部分节点被攻破，OAuth Share 和用户身份信息仍然是安全的。

5. 数据同步和更新​

  • 链上数据更新：当用户在链上进行操作（如转账、交易）时，智能合约会更新相关的链上数据。
  • 用户 ID 关联更新：如果用户添加新的社交登录方式或设备，Web3Auth 会更新用户 ID 与新的 OAuth Share 的关联关系。这种更新通过分布式节点的协同工作来实现。

示例流程​

  1. 用户首次登录：

    • 用户通过 Discord 进行首次登录，生成 OAuth Share 和用户 ID。
    • 用户 ID 与链上数据在智能合约中进行映射。

  2. 用户添加新的社交登录方式（如 Chrome）：

    • 用户通过多因素验证添加新的社交登录方式。
    • Web3Auth 生成新的 OAuth Share，并与用户 ID 进行关联。

  3. 用户访问链上数据：

    • 用户通过 Chrome 进行登录，重建 OAuth Share。
    • 系统验证用户身份，允许访问和操作链上数据。

总结​

通过用户 ID、智能合约、分布式节点和加密分享，Web3Auth 能够有效地维护链上数据与用户的映射关系。去中心化的存储和管理方式提高了系统的安全性和隐私保护，确保用户能够安全、便捷地访问和操作链上数据。

谁来检测 Social login ,之前构建授权链接是 python 之类的服务端程序来构建的，现在如何构建？​

在 Web3Auth 的去中心化架构中，社交登录（Social Login）的检测和授权链接的构建不再依赖传统的集中式服务端，而是通过前端和去中心化服务来实现。以下是详细的步骤和方法：

1. 前端构建授权链接​

  • OAuth 2.0 流程：Web3Auth 利用 OAuth 2.0 协议来实现社交登录。前端应用可以直接与 OAuth 提供商（如 Google、Discord 等）交互，构建授权链接。
  • SDK 支持：Web3Auth 提供了前端 SDK，帮助开发者简化与 OAuth 提供商的交互过程。SDK 会自动处理授权链接的构建和重定向。

2. 用户授权和回调​

  • 用户授权：用户点击登录按钮后，前端应用会将用户重定向到 OAuth 提供商的授权页面。用户在授权页面上进行登录和授权操作。
  • 回调处理：用户授权成功后，OAuth 提供商会将用户重定向回前端应用的回调 URL，并附带授权码（authorization code）。

3. 获取访问令牌​

  • 交换授权码：前端应用接收到授权码后，可以使用 Web3Auth SDK 与 OAuth 提供商的 Token Endpoint 交换授权码，获取访问令牌（access token）。
  • 去中心化服务：在某些情况下，Web3Auth 可能会利用去中心化服务或分布式节点来协助处理授权码交换和令牌获取，以确保整个过程的安全性和去中心化特性。

4. 用户身份验证和设备分享​

  • 验证用户身份：前端应用使用获取到的访问令牌，通过 Web3Auth SDK 验证用户身份。SDK 会与去中心化节点协作，确保用户身份的合法性和安全性。
  • 生成设备分享：用户身份验证成功后，Web3Auth SDK 会生成新的设备分享，并与用户 ID 进行关联。

示例流程​

  1. 前端构建授权链接：

    • 用户点击登录按钮，前端应用使用 Web3Auth SDK 构建 OAuth 授权链接。
    • 用户被重定向到 OAuth 提供商的授权页面。

  2. 用户授权和回调：

    • 用户在授权页面上进行登录和授权操作。
    • OAuth 提供商将用户重定向回前端应用的回调 URL，并附带授权码。

  3. 获取访问令牌：

    • 前端应用使用 Web3Auth SDK 与 OAuth 提供商交换授权码，获取访问令牌。
    • Web3Auth SDK 可能会利用去中心化服务或分布式节点协助处理授权码交换。

  4. 用户身份验证和设备分享：

    • 前端应用使用访问令牌，通过 Web3Auth SDK 验证用户身份。
    • 验证成功后，生成新的设备分享，并与用户 ID 进行关联。

总结​

在 Web3Auth 的去中心化架构中，社交登录的检测和授权链接的构建主要通过前端应用和 Web3Auth SDK 来实现，而不依赖于传统的集中式服务端。前端应用直接与 OAuth 提供商交互，利用去中心化服务和分布式节点确保用户身份验证和设备分享的安全性和去中心化特性。

Social login OAuth 成功后，web3auth SDK 还要再进行用户身份验证？这个是如何实现的​

在 Web3Auth 的架构中，社交登录（Social Login）和 OAuth 成功后，确实需要进行进一步的用户身份验证。这个过程主要是为了确保用户身份的合法性和安全性，特别是在去中心化环境中。以下是详细的步骤和实现方式：

1. 社交登录和 OAuth 成功​

  • 用户授权：用户通过前端应用进行社交登录（例如使用 Google、Discord 等）。
  • 获取授权码：用户成功授权后，前端应用从 OAuth 提供商处获取授权码。
  • 获取访问令牌：前端应用使用 Web3Auth SDK 与 OAuth 提供商的 Token Endpoint 交换授权码，获取访问令牌（access token）。

2. Web3Auth SDK 进行用户身份验证​

  • 验证访问令牌：Web3Auth SDK 使用获取到的访问令牌与去中心化节点或 Web3Auth 服务器进行交互，验证访问令牌的合法性。
  • 获取用户信息：验证成功后，Web3Auth SDK 从 OAuth 提供商处获取用户信息（如用户 ID、邮箱等）。

3. 多因素验证和 OAuth Share 重建​

  • 多因素验证：为了确保安全性，Web3Auth 可能会要求用户进行多因素验证（如再次通过社交登录、短信验证码等）。
  • 分布式存储和重建：
    • 获取加密分享：Web3Auth SDK 从分布式节点获取用户的加密分享（shares）。
    • 门限重建：满足门限条件后，重建用户的 OAuth Share。

4. 生成设备分享和链上操作​

  • 生成设备分享：用户身份验证成功并重建 OAuth Share 后，Web3Auth SDK 会生成新的设备分享（Device Share），并与用户 ID 进行关联。
  • 链上操作：用户可以使用重建的 OAuth Share 和设备分享进行链上操作（如签名交易、访问去中心化应用等）。

示例代码​

以下是一个简化的示例代码，展示了如何使用 Web3Auth SDK 进行用户身份验证：

import { Web3Auth } from '@web3auth/web3auth';
import { OpenloginAdapter } from '@web3auth/openlogin-adapter';

const web3auth = new Web3Auth({
  clientId: 'YOUR_CLIENT_ID', // 从Web3Auth获取的客户端ID
  chainConfig: {
    chainNamespace: 'eip155',
    chainId: '0x1', // 以太坊主网
    rpcTarget: 'https://mainnet.infura.io/v3/YOUR_INFURA_PROJECT_ID', // RPC节点
  },
});

const openloginAdapter = new OpenloginAdapter({
  adapterSettings: {
    network: 'mainnet',
    clientId: 'YOUR_CLIENT_ID',
    uxMode: 'popup',
    loginConfig: {
      google: {
        verifier: 'YOUR_GOOGLE_VERIFIER',
        typeOfLogin: 'google',
        clientId: 'YOUR_GOOGLE_CLIENT_ID',
      },
      // 其他社交登录配置
    },
  },
});

web3auth.configureAdapter(openloginAdapter);

async function login() {
  await web3auth.initModal();
  const provider = await web3auth.connect();
  const user = await web3auth.getUserInfo();
  console.log('User Info: ', user);

  // 此处进行多因素验证和OAuth Share重建
  // ...

  // 生成设备分享并进行链上操作
  // ...
}

login().catch(console.error);

总结​

在 Web3Auth 的去中心化架构中，社交登录和 OAuth 成功后，Web3Auth SDK 会进一步进行用户身份验证。这个过程包括验证访问令牌、获取用户信息、多因素验证、从分布式节点获取加密分享、重建 OAuth Share 以及生成设备分享。通过这些步骤，确保用户身份的合法性和安全性，并支持进一步的链上操作。

web3auth sdk 源码​

找身份验证那块代码看下逻辑