¿Cuándo debo utilizar este flujo?

Si App ID no proporciona soporte directo para un proveedor de identidad en concreto, puede utilizar el flujo de identidad personalizado para establecer un puente en el protocolo de autenticación hacia el flujo de autenticación existente de App ID. Por ejemplo, desea utilizar GitHub o LinkedIn para permitir a los usuarios iniciar sesión. Puede utilizar el SDK existente del proveedor de identidad para facilitar la información de autenticación de usuario antes de empaquetarla e intercambiarla con App ID.

Existen muchos casos de ejemplo en los que es necesario un flujo de autenticación distinto:

• Proveedores de identidad internos y de propiedad
• Proveedores de identidad de terceros
• Flujos de autenticación complicados que pueden incluir mecanismos de multifactores de propiedad

Ocasionalmente, un proveedor heredado puede utilizar su propio protocolo de autenticación personalizado. Puesto que el flujo de identidad personalizado desacopla completamente la autenticación de la autorización, puede adoptar cualquier mecanismo de autenticación de su elección y proporcionar la información de autenticación resultante a App ID. Todo ello sin exponer las credenciales de usuario.

Técnicamente, ¿cómo funciona este flujo?

El flujo de trabajo de identidad personalizado se basa en el tipo de concesión de extensión JWT-Bearer que se define en Assertion Framework for OAuth 2.0 Authorization Grants [RFC7521 ]. Para poder intercambiar información de usuario para las señales de App ID, la arquitectura de autenticación crea una relación de confianza con App ID utilizando un par de claves RSA asimétricas. Una vez se haya establecido la confianza, puede utilizar el tipo de otorgamiento JWT-Bearer para intercambiar información de usuario verificada en un JWT firmado para las señales App ID.

¿Qué aspecto tiene el flujo?

Al igual que todos los flujos de autenticación, la identidad personalizada requiere que la aplicación sea capaz de establecer un grado de confianza con App ID para garantizar la integridad de la información de usuario del proveedor de identidad. La identidad personalizada utiliza un par de claves públicas y privadas de RSA asimétricas para establecer la relación de confianza. En función de los requisitos arquitectónicos, la identidad personalizada admite dos modelos de confianza que difieren únicamente en la ubicación del almacenamiento y el uso de la clave privada.

Formato JWT de ejemplo

{
  // 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"
}