我何时需要使用此流程？

App ID 未提供对特定身份提供者的直接支持时，您可以使用定制身份流程将认证协议桥接到 App ID 的现有认证流程。 例如，您希望使用 GitHub 或 LinkedIn 来允许用户登录。 可以使用身份提供者的现有 SDK 来方便地提供用户认证信息，然后打包这些信息，并将其与 App ID 进行交换。

在许多情况下，需要不同的认证流程：

• 专有内部身份提供者
• 第三方身份提供者
• 复杂认证流程，可包括专有多因子机制

有时，原有提供者可能会使用其自己的定制认证协议。 由于定制身份流程使认证与授权完全相分离，因此可以采用所选的任何认证机制，然后向 App ID 提供生成的认证信息。 所有机制都不会公开用户凭证。

从技术角度来说，此流程是如何运作的？

自定义身份认证工作流程建立在 JWT-Bearer 扩展授权类型之上，该类型在 OAuth 2.0 Authorization Grants 的断言框架 [RFC7521 ]中有所定义。 为交换 App ID 令牌的用户信息，您的身份验证架构会使用非对称 RSA 密钥对与 App ID 建立信任关系。 建立了信任后，就可以使用 JWT-Bearer 授权类型，用已签名 JWT 中已验证的用户信息来交换 App ID 令牌。

此流程是什么样子的？

与所有认证流程一样，定制身份也需要应用程序能够与 App ID 建立一定程度的信任关系，以确保身份提供者用户信息的完整性。 定制身份利用非对称 RSA 公用和专用密钥对来建立其信任关系。 根据体系结构需求，定制身份支持两种信任模型，区别仅在于专用密钥的存储位置和用途。

示例 JWT 格式

{
  // Header
  "alg": "RS256",
  "typ": "JOSE",
  // Payload
  // Required
  "iss": "String", // Should reference your identity provider
  "aud": "String", // Must be the OAuth server URL name
  "exp": "Int",    // Should be a value with a short lifespan
  "sub": "String", // Must be the unique user ID provided by your identity provider

  // Normalized claims (optional)
  "name": "String",
  "email": "String",
  "locale": "String",
  "picture": "String",
  "gender": "String",

  // Custom Scopes to add to access token (optional)
  scope="custom_scope1 custom_scope2"

  // Other custom claims (optional)
  role="admin"
}