身份认证：终端用户登录、通行密钥与会话

身份验证用于让您的客户登录您的应用。它与登录 Didit 控制台或创建 Didit 开发者账户是分开的，也与验证某人的身份是分开的。 您可以单独使用身份验证，也可以将其与身份证件验证和交易监控结合使用。登录并不代表批准验证，也不代表授权付款。您的后端应根据各产品自身的结果做出这些决定。

​

工作原理

每个应用都有自己的登录来源和自己的 token 颁发方。生产应用和沙盒应用是分开的：它们拥有各自的来源、设置和身份标识。 该流程采用带 PKCE 的 OAuth 2.0 授权码模式（仅支持 S256）：

1. 您的应用使用 redirect_uri、state、code_challenge 和 code_challenge_method=S256 打开 {origin}/sign-in。
2. 托管页面使用您启用的方式让用户登录或注册，包括所需的第二因素验证。
3. 浏览器携带 code 和 state 返回您的 redirect_uri。
4. 您的应用在 POST {origin}/token/ 处用授权码换取访问 token、ID token 和刷新 token。

token 协定请参阅 token 与 JWKS，各登录方式请参阅 登录方式。

​

选择您的平台

​

准备您的应用

1. 请求 Didit 为您的应用开启身份验证。请先在沙盒应用中测试。
2. 注册您精确的重定向 URL（最多 50 个），以及调用运行时 API 的浏览器 allowed_origins（最多 50 个）。
3. 启用您希望提供的登录方式。Didit ID Wallet 始终处于开启状态。
4. 选择您的会话和密码设置（见下文）。
5. 正式上线前，请测试注册、登录、忘记密码、MFA、会话过期和退出登录。

通行密钥属于其所在的来源。如果您之后激活自定义域名，用户必须重新注册其通行密钥。

​

重定向 URL

Didit 只会将用户重定向到您已注册的地址。 请在控制台中注册您的地址，位置为 Authentication > Security and sessions > Redirect URLs and allowed origins。 登录请求中的 redirect_uri 必须与已注册的 URL 逐字符一致：协议、主机、端口、路径和查询参数都要相同。 端口不同、结尾多一个斜杠或字母大小写不同，都属于不同的地址。 包含通配符、片段、URL 中的凭据以及自定义协议的地址会被拒绝。 如果地址未注册，Didit 绝不会重定向到该地址。 {origin}/sign-in 会返回 400，并显示一个页面，说明需要注册什么以及在哪里注册；POST {origin}/authorize/ 会返回 400 {"error": "invalid_redirect_uri"}。

​

本地开发

请使用您的沙盒应用，在自己的计算机上进行测试：

1. 注册带端口的回调地址，例如 http://localhost:3000/auth/callback。
2. 如果浏览器代码会调用运行时 API，例如在 POST {origin}/token/ 处用授权码换取 token，还需将该来源添加到 允许的来源：http://localhost:3000，不带路径，也不带结尾斜杠。
3. 使用您的 pk_test_... 密钥，从沙盒来源 https://<slug>.sandbox.auth.didit.me 开始登录。

localhost、127.0.0.1 和 [::1] 是不同的地址，每个端口也各不相同。 您使用的每一个都需要单独注册。 生产应用从不接受 http://。 正式上线前，请在您的生产应用上注册生产环境的 https:// 回调地址。

​

应用设置

您可以在控制台中管理这些设置，也可以使用具有 write:authentication 权限的控制台会话进行管理。

​

在各产品间保持同一用户

每个身份都带有一个 vendor_data 值。如果您通过导入方式添加过该用户，它就是您提供的 external_id；否则为 Didit 身份 ID。它会出现在访问令牌、ID 令牌和 GET session/ 中。 在创建验证会话和提交交易时，请使用相同的值作为 vendor_data。这样，认证事件就会在控制台中归入同一用户，与其验证和交易记录一起显示。请参阅事件与 Webhook。 请在后端从已验证的令牌中获取 vendor_data，切勿从未经校验的浏览器字段中获取。 任何组合都可以使用共享集成提示词。有关登录时运行的策略，请阅读机器人防护。