我何時該使用此流程？

當 App ID 沒有提供特定身分提供者的直接支援時，您可以使用自訂身分流程，將鑑別通訊協定橋接至 App ID 的現有鑑別流程。 例如，您要使用 GitHub 或 LinkedIn 來容許使用者登入。 您可以使用身分提供者的現有 SDK 來協助使用者鑑別資訊，然後將其包裝並與 App ID 交換。

有許多情境，需要不同的鑑別流程：

• 專屬的內部身分提供者
• 協力廠商身分提供者
• 複雜的鑑別流程，其中可以包括專屬的多因子機制

有時，舊式提供者可能會使用自己的自訂鑑別通訊協定。 因為自訂身分流程會完全取消鑑別與授權的連結，所以您可以採用任何您選擇的鑑別機制，然後將產生的鑑別資訊提供給 App ID。 完全不公開使用者認證。

在技術上，這個流程如何運作？

自訂身分工作流程建基於 JWT-Bearer 延伸授予類型，此類型已在 Assertion Framework for 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"
}