API de identidad desatendida: Flujo de registro desatendido para clientes privados
Para aplicaciones que pueden mantener información confidencial, como aplicaciones web con una arquitectura de servidor cliente, puede configurar el registro desatendido para clientes y socios utilizando el Flujo de registro desatendido. El proceso de inicio de sesión desatendido con el flujo Código de autorización y credenciales, que se construye sobre el tipo de otorgamiento de Código de autorización de OAuth 2.0. Con este flujo, controla la experiencia de registro de usuarios de cara al público en una aplicación externa. Llama API de registro desatendido de Salesforce a través de su sitio de Experience Cloud para crear usuarios, iniciar sesión y otorgarles acceso a recursos de Salesforce. Separando estos dos procesos, sus usuarios pueden registrarse en su aplicación y acceder a datos de Salesforce sin salir de la aplicación.
Ediciones necesarias
| Disponible en: Salesforce Classic (no disponible en todas las organizaciones) y Lightning Experience |
| Disponible en: Enterprise Edition, Unlimited Edition y Developer Edition |
Este es un caso de uso de ejemplo para implementar el flujo Registro desatendido. Usted trabaja para una compañía de viajes que gestiona información de clientes en Salesforce. Es importante que tenga un control completo sobre la experiencia de usuario en la aplicación. También desea retener más clientes animándolos a registrarse en su aplicación, lo que requiere servicios de identidad. Como su compañía ya utiliza Salesforce, Identidad desatendida es el camino a seguir. Crea una aplicación de cliente-servidor tradicional y configura el Flujo de registro desatendido. Cuando los nuevos usuarios se inscriban en su aplicación, se les saluda con su experiencia de registro personalizada. Se registran, verifican su identidad y acceden a datos de Salesforce sin interactuar directamente con Salesforce.
Para ampliar sus opciones de plantilla de email para el email de contraseña simultánea (OTP) enviado a usuarios finales durante el flujo, suscriba a la lista de admisión de plantillas de email y cree una lista de admisión con plantillas personalizadas. Consulte Utilizar múltiples plantillas de email para flujos desatendidos.
Antes de configurar este flujo, configure los parámetros y las políticas de acceso necesarios en su aplicación conectada o aplicación cliente externa. Consulte Configurar una aplicación conectada para el flujo Código de autorización y credenciales o Configurar una aplicación cliente externa para el flujo Código de autorización y credenciales.
A continuación se incluye una descripción general del flujo.
- Un usuario abre su aplicación y hace clic en Registrarse. (1)
- En su aplicación, muestra de forma nativa un formulario de registro para recopilar datos de usuarios. Usted diseña este formulario y personaliza la información que desea recopilar. (2)
- El usuario ingresa su información en la aplicación. Por ejemplo, ingresa su nuevo nombre de usuario, contraseña y nombre. (3)
- Su aplicación envía la información de usuario al extremo de API de registro desatendido /services/auth/headless/init/registration en su sitio de Experience Cloud. (4)
- Salesforce recibe la información de usuario y la pone en cola para procesar más adelante. Salesforce devuelve un mensaje de operación correcta que incluye un Id. de solicitud de registro a su aplicación. (5a)
- Salesforce envía a continuación un email o un mensaje de texto SMS que contiene una contraseña simultánea (OTP) al usuario. (5b)
- En su aplicación, muestra de forma nativa un formulario de verificación OTP. Selecciona cómo desea que se muestre este formulario. (6)
- El usuario recibe su OTP e lo ingresa en el formulario de verificación. (7)
- Su aplicación inicia a continuación el flujo Código de autorización y credenciales con una solicitud de código de autorización a la API de inicio de sesión desatendido. La solicitud incluye la OTP y un Id. de solicitud, junto con otros parámetros. (8)
- Salesforce verifica el Id. de la solicitud y la OTP. Recupera los datos de usuario en cola que almacenaba anteriormente y llama al controlador de registro desatendido. El controlador de registro desatendido crea un usuario en Salesforce. (9)
- Salesforce devuelve un redireccionamiento 302 a una URL preconfigurada que contiene el código de autorización. El redireccionamiento 302 se procesa dentro del navegador, y la respuesta se entrega de forma desatendida a su controlador de devolución de llamadas preconfigurado en su servidor. (10)
- El controlador de devolución de llamadas del lado del servidor extrae el código de autorización y otros parámetros de la de redireccionamiento 302. A continuación inicia el intercambio de códigos enviando una solicitud POST sin encabezado al extremo del token. (11)
- Desde el extremo de tokens, Salesforce devuelve una respuesta de token de acceso al controlador de devolución de llamadas del lado del servidor. (12)
- El controlador de devolución de llamadas del lado del servidor procesa la respuesta del token y devuelve el estado de inicio de sesión a la aplicación. Esta respuesta puede incluir detalles de sesión, información de usuario y posiblemente el token de acceso, dependiendo del diseño y el estado de seguridad de su aplicación. (13)
- El navegador recibe la respuesta iniciada y crea la sesión del usuario. (14)
- El usuario ahora inició sesión y realiza una acción en su aplicación personalizada que inicia una solicitud de datos de Salesforce. Por ejemplo, hace clic en un botón para acceder a su historial de reserva de viajes, que se almacena en el sitio de Experience Cloud de Salesforce. (15)
- Su aplicación personalizada realiza una solicitud autenticada a un extremo de Salesforce protegido, como una API de Salesforce. (16)
- El cliente ahora puede acceder a sus datos protegidos en su aplicación personalizada. Por ejemplo, puede ver su historial de reserva de viajes. (17)
El usuario abre la aplicación externa e inicia sesión
Su usuario abre su aplicación y hace clic en un vínculo de registro o hace clic en un vínculo para acceder a un recurso que requiere registro.
Su aplicación muestra un formulario de registro
En su aplicación, muestra de forma nativa un formulario de registro para recopilar datos de usuarios. Usted controla todo acerca de este formulario, incluyendo su aspecto, su comportamiento y la información de usuario que desea recopilar.
Existen algunas consideraciones sobre la información que desea recopilar de usuarios. Cuando su aplicación envía información de usuario a la API de registro desatendido, Salesforce comprueba una dirección de email, un nombre de usuario, un apellido y una contraseña. Puede recopilar esta información a usuarios o generarla automáticamente, pero debe incluirse en su solicitud POST. Cuando decida qué información incluir, asegúrese de recopilar una dirección de email o número de teléfono de modo que el usuario pueda verificar su identidad.
El usuario ingresa su información
En su aplicación, el usuario ingresa su información en su formulario de registro.
Su aplicación envía información de usuario a la API de registro desatendido
Desde el navegador, su aplicación envía una solicitud POST al extremo de registro desatendido (/services/auth/headless/init/registration ) en su sitio de Experience Cloud utilizando Java asíncrono y XML (AJAX).
Incluya estos encabezados en su solicitud de registro.
| Encabezado | ¿Obligatorio? | Descripción |
|---|---|---|
Authorization: Bearer
|
Este encabezado es obligatorio si activa Requerir autenticación para acceder a esta API en la página Inicio de sesión y registro de Experience Cloud. Le recomendamos encarecidamente activar siempre este ajuste para clientes privados. | Contiene un token de acceso emitido a un usuario de integración interno. Para obtener el token de acceso, puede utilizar cualquier flujo de OAuth estándar que admita Salesforce. Asegúrese de asignar el ámbito user_registration_api a su aplicación conectada o aplicación cliente externa, o páselo como un parámetro durante su flujo. |
Content-Type
|
No. Si está utilizando Postman para crear y probar su flujo, a veces agrega este encabezado. Verifique que es correcto comprobando los encabezados ocultos. | Especifica el formato de su solicitud, como application/json. |
Incluya estos parámetros en el cuerpo de la solicitud.
| Parámetro | ¿Obligatorio? | Descripción |
|---|---|---|
password
|
Sí. | La contraseña del usuario. La contraseña está sujeta a cualquier política de contraseña configurada para el perfil o la organización. |
userdata
|
Sí. Incluso si no recopila esta información del usuario, la debe generar automáticamente y pasarla en el parámetro userdata. |
Contiene toda la información de usuario obligatoria. Como mínimo, Salesforce precisa de esta información en el parámetro
|
recaptcha
|
Obligatorio si se le aplican estas condiciones.
|
Un token cifrado emitido por la API de reCAPTCHA de Google cuando un usuario completa un reto de reCAPTCHA. |
recaptchaevent
|
Obligatorio si se le aplican estas condiciones:
|
Un objeto JSON que contiene estos subparámetros.
Para obtener más información, consulte la documentación de reCAPTCHA de Google. |
verificationmethod
|
No. Si no incluye este parámetro, Salesforce toma como valor predeterminado la verificación de la identidad del usuario con email. Si incluye este parámetro, incluya un encabezado |
El método utilizado para verificar la identidad del usuario. Salesforce admite dos valores para el método de verificación: email y sms. |
customdata
|
No. | Contiene cualquier información de usuario personalizada que recopile. Por ejemplo, puede incluir la dirección de calle del usuario. |
emailtemplate
|
Se requiere especificar varias plantillas de email si se activa la lista de admisión de plantillas de email. Si no activó la lista de admisión de plantillas de email, no puede incluir este parámetro. Si no incluye este parámetro, Salesforce utiliza la plantilla de email predeterminada configurada en su configuración de Experience Cloud, independientemente de si la lista de admisión está activada. Si no hay ninguna plantilla configurada, Salesforce utiliza una plantilla de email OTP predeterminada. |
El nombre del desarrollador de la plantilla de email personalizada. Este parámetro solo puede incluir una plantilla de email desde la lista de admisión. |
A continuación se incluye un ejemplo de solicitud. En este ejemplo, los parámetros de Experience Cloud están configurados para requerir tanto autenticación como reCAPTCHA, de modo que la solicitud incluye un token de acceso y un token de reCAPTCHA.
POST /services/auth/headless/init/registration? HTTP 1.1
Host: MyDomainName.my.site.com
Content-Type: application/json
Authorization: Bearer **************
{
“userdata”: {
“firstName”: “Janice”
“lastName”: “Edwards”
“email”: “janice.edwards@example.com”
“username”: “jedwards@myapp.com”
}
“customdata”: {
{”mobilePhone”=”<mobile phone number>”
}
“password”: “*******”
“recaptcha”:”***********”
“verificationmethod”: “email”
“emailtemplate”: “unfiled$public/SalesNewCustomerEmail”
}Salesforce recibe la información y devuelve un identificador de solicitud
Salesforce recibe la información del usuario. Como Salesforce no verificó la identidad del usuario, lleva a la cola esta información para que se procese más tarde.
Si la información de la solicitud POST es válida, Salesforce devuelve un mensaje de operación correcta a la aplicación. Este mensaje incluye un identificador de solicitud de registro, que es importante más adelante en el flujo. A continuación se incluye un mensaje de operación realizada correctamente de ejemplo.
{
"status": "success",
"email": “jedwards@myapp.com”
"identifier": “0RXXXXXXXX”
}Salesforce envía una contraseña simultánea al usuario
Tras recibir inmediatamente los datos de usuario de Salesforce y enviar un mensaje de operación correcta a la aplicación, envía una contraseña simultánea (OTP) a través de email o SMS, dependiendo del método de verificación del usuario.
Su aplicación muestra de forma nativa un formulario de verificación
Cuando recibe el mensaje de operación correcta, muestra de forma nativa un formulario de verificación OTP en su aplicación. Nuevamente, el aspecto de la experiencia de verificación depende completamente de usted.
El usuario ingresa una OTP en el formulario de verificación
Su usuario recibe la OTP a través de email o SMS y la ingresa en su formulario de verificación.
Configurar el flujo Código de autorización y credenciales
Cuando el usuario prueba su identidad, la aplicación inicializa inmediatamente el Código de autorización y el flujo de credenciales con una solicitud en la API de inicio de sesión desatendido.
Incluya estos encabezados en su solicitud de autorización
| Encabezado | ¿Obligatorio? | Descripción |
|---|---|---|
Auth-Request-Type
|
Sí. | Especifica el tipo de solicitud que desea realizar a Salesforce. Para el registro desatendido, este valor debe establecerse en user-registration. |
Authorization
|
Sí. | Un encabezado básico que identifica la solicitud de registro de modo que Salesforce pueda vincularla a la información almacenada del usuario. Debe incluir el identificador de solicitud que le proporcionó Salesforce y el valor de OTP utilizado para verificar la identidad del usuario. Anexe estos valores entre sí con el formato |
Content-Type
|
No. Si está utilizando Postman para crear y probar su flujo, a veces agrega este encabezado. Verifique que es correcto comprobando los encabezados ocultos. | Especifica el formato de su solicitud, como application/x-www-form-urlencoded. |
Auth-Verification-Type
|
Es obligatorio si especificó un método de verificación de identidad en su solicitud de registro inicial. El valor de este encabezado debe coincidir con el valor del parámetro de cuerpo verificationmethod de su solicitud al extremo /services/auth/headless/init/registration. |
El método utilizado para verificar la identidad del usuario. Salesforce admite dos valores para el método de verificación: email y sms. |
Uvid-Hint
|
No. Si implementa el flujo de usuarios invitados en su aplicación, puede opcionalmente utilizar este encabezado para pasar en un token de acceso basado en Token web de JSON (JWT) que contenga un Id. de visitante exclusivo (UVID) vinculado a la identidad de un usuario invitado. Al pasar el UVID a un flujo de usuario nombrado, puede llevar información contextual desde una sesión de usuario invitado, como las preferencias de cookies del usuario, a una sesión de usuario nombrada. En lugar de pasar un token basado en JWT con un UVID en un encabezado, también puede pasar el valor UVID sin formato en el cuerpo de la solicitud. |
Un token de acceso basado en JWT que contiene un valor UVID, que es un identificador exclusivo universal (UUID) de Versión 4 que su aplicación genera y gestiona completamente. Para obtener un token de acceso con un UVID, debe activar su aplicación conectada o aplicación cliente externa para emitir tokens de acceso basados en JWT e implementar el flujo de invitados desatendido en su aplicación. |
Incluya estos parámetros en el cuerpo de la solicitud.
| Parámetro | ¿Obligatorio? | Descripción |
|---|---|---|
client_id
|
Sí. | El secreto de consumidor de la aplicación conectada o la aplicación cliente externa. |
response_type
|
Sí. | El tipo de otorgamiento de OAuth 2.0 que solicita la aplicación conectada o la aplicación cliente externa. Para el flujo Código de autorización y credenciales, el valor debe ser code_credentials. |
redirect_uri
|
Sí. | La URL donde se redirige a los usuarios después de una autenticación satisfactoria. redirect_URI debe coincidir con uno de los valores del campo URL de devolución de llamada de la aplicación conectada o la aplicación cliente externa. De lo contrario, la aprobación falla. Este valor debe tener codificación de URL. |
uvid_hint
|
No. Si implementa el flujo de usuario invitado en su aplicación, puede utilizar opcionalmente este parámetro para pasar en un valor UVID vinculado a la identidad de un usuario invitado, incluyendo información contextual desde una sesión de usuario invitado en una sesión de usuario nombrada. En lugar de pasar el identificador UVID en el cuerpo de la solicitud, también puede lo pasar en un token basado en JWT con un UVID a través del encabezado |
Un valor UVID sin formato, que es un UUID de versión 4 que su aplicación genera y gestiona. Para obtener un UVID, debe activar su aplicación conectada o aplicación cliente externa para emitir tokens de acceso basados en JWT e implementar el flujo de invitados desatendido en su aplicación. |
code_challenge
|
Solo si está utilizando PKCE. | Obligatorio si se utiliza la extensión PKCE. Especifica el valor de hash SHA256 del valor Este parámetro es necesario si se especifica un verificador
|
A continuación se incluye un ejemplo de solicitud a API de inicio de sesión desatendido, incluyendo PKCE.
POST /services/oauth2/authorize? HTTP 1.1
Host: MyDomainName.my.site.com
Auth-Request-Type: user-registration
Auth-Verification-Type: email
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <base64-encoded request ID:OTP>
response_type=code_credentials&
client_id=******&
redirect_uri=https://www.MyDomainName.my.site.com/services/apexrest/code/exchange&
code_challenge=Y29kZ*******
Salesforce verifica la solicitud, recupera los datos de usuario y crea el usuario
Salesforce recibe la solicitud de autorización y verifica el Id. de solicitud y el OTP. Salesforce utiliza esta información para recuperar los datos de usuario en cola y llamar al controlador de registro desatendido configurado en su sitio de Experience Cloud. El gestor de Apex crea el usuario en Salesforce y lo vincula a una cuenta.
Salesforce devuelve un redireccionamiento 302 a una URL preconfigurada que contiene el código
Salesforce devuelve un redireccionamiento HTTP 302 a una URL preconfigurada que contiene el código de autorización. El redireccionamiento 302 se procesa dentro del navegador, y la respuesta se entrega de forma desatendida a la URL de redireccionamiento, que es un extremo de devolución de llamada preconfigurado en su servidor. Esta es una URL de ejemplo.
https://www.MyDomainName.my.site.com/services/apexrest/code/exchange?code=aPrxC1*******
&sfdc_community_url=https%3A%2F%2FMyDomainName.my.site.com&sfdc_community_id=0DBxxxxxxxxxxxxEl controlador de devolución de llamadas extrae el código y realiza el intercambio de códigos
El controlador de devolución de llamadas del lado del servidor extrae el código de autorización y otros parámetros de la de redireccionamiento 302. A continuación inicia el intercambio de códigos enviando una solicitud POST sin encabezado al extremo del token.
Para la solicitud de token de acceso, solo puede utilizar una solicitud POST: No se admiten las solicitudes GET. No hay encabezados obligatorios para esta solicitud, pero puede incluir un encabezado Content-Type.
| Encabezado | ¿Obligatorio? | Descripción |
|---|---|---|
Content-Type
|
No. Si está utilizando Postman para crear y probar su flujo, a veces agrega este encabezado. Verifique que es correcto comprobando los encabezados ocultos. | Especifica el formato de su solicitud, como application/x-www-form-urlencoded. |
Incluya estos parámetros en el cuerpo de la solicitud.
| Parámetro | ¿Obligatorio? | Descripción |
|---|---|---|
client_id
|
Sí. | La clave de consumidor de la aplicación conectada o la aplicación cliente externa. |
client_secret
|
Sí. | El secreto de consumidor de la aplicación conectada o la aplicación cliente externa. |
code
|
Sí. | El servidor de autorización crea un código de autorización, que es un token efímero que pasa al cliente después de una autenticación correcta. El cliente envía el código de autorización al servidor de autorización para obtener un token de acceso y, opcionalmente, un token de actualización. |
code_verifier
|
Obligatorio si se utiliza la extensión PKCE. | Especifica 128 bytes de datos aleatorios con alta entropía para hacer que sea difícil adivinar el valor de
|
format
|
No. | El formato esperado de la respuesta. Salesforce admite estos formatos.
|
grant_type
|
Sí. | El tipo de validación que la aplicación conectada o la aplicación cliente externa puede proporcionar para probar que es un visitante seguro. Para el flujo Código de autorización y credenciales, el valor debe ser authorization_code. |
redirect_uri
|
Sí. | La URL donde se redirige a los usuarios después de una autenticación satisfactoria. redirect_URI debe coincidir con uno de los valores del campo URL de devolución de llamada de la aplicación conectada o la aplicación cliente externa. Este valor debe tener codificación de URL. |
A continuación se incluye una solicitud de token de ejemplo.
POST /services/oauth2/token HTTP 1.1
Host: MyDomainName.my.site.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&
code=aPrxC1*******&
client_id=******&
client_secret=******&
redirect_uri=https://www.MyExperienceCloudSite.my.site.com/services/apexrest/code/exchange&
code_verifier=Y29kZ*******
Salesforce otorga un token de acceso
Salesforce valida la solicitud de token y devuelve una respuesta de token de acceso al controlador de devolución de llamadas del lado del servidor. A continuación se incluye un ejemplo de respuesta de token de acceso en formato JSON.
{
"access_token":"*******************",
"sfdc_community_url":"https://MyDomainName.my.site.com",
"sfdc_community_id":"0DBxxxxxxxxxxxx",
"signature":"ts6wm/svX3jXlCGR4uu+SbA04M6qhD1SAgVTEwZ59P4=",
"scope":"openid api",
"id_token":"XXXXXX",
"instance_url":"https://yourInstance.salesforce.com",
"id":"https://yourInstance.salesforce.com/id/00Dxxxxxxxxxxxx/005xxxxxxxxxxxx",
"token_type":"Bearer",
"issued_at":"1667600739962"
}La respuesta del token de acceso contiene estos parámetros.
| Parámetro | ¿Obligatorio? | Descripción |
|---|---|---|
access_token
|
Sí. | Token de OAuth que una aplicación conectada o aplicación cliente externa utiliza para solicitar el acceso a un recurso protegido en nombre de la aplicación cliente. Pueden acompañar permisos adicionales en la forma de ámbitos al token de acceso. |
id
|
Sí. | Una URL de identidad que se puede utilizar para identificar al usuario y para consultar con el fin de obtener más información acerca del usuario. Consulte URL de identidad. |
id_token
|
No. | |
instance_url
|
Sí. | Una URL que indica la instancia de la organización del usuario. Por ejemplo: https://yourInstance.salesforce.com/. |
issued_at
|
Sí. | Marca de hora de la creación de la firma, expresada como el número de milisegundos desde 1970-01-01T0:0:0Z UTC. |
refresh_token
|
No. | Token obtenido del servidor web, usuario-agente o flujo de token de aplicación híbrida. Se trata de un valor secreto. Tome las medidas apropiadas para protegerlo. Este parámetro se devuelve únicamente si su aplicación conectada o aplicación cliente externa se configura con un ámbito refresh_token. |
signature
|
Sí. | Firma HMAC-SHA256 con codificación Base64 firmada con client_secret. La firma puede incluir el Id. concatenado y issued_at value, que puede utilizar para verificar que la dirección URL de identidad no ha cambiado desde que la envió el servidor. |
sfdc_community_url
|
Sí. | La URL del sitio de Experience Cloud. |
sfdc_community_id
|
Sí. | El Id. de sitio de Experience Cloud del usuario. |
state
|
No. | El estado solicitado por el cliente. Este valor solo se incluye si el parámetro state ya estaba en la cadena de consulta original. |
token_type
|
Sí. | Un tipo de token Bearer, que se utiliza para todas las respuestas que incluyen un token de acceso. |
El controlador de devolución de llamadas procesa la respuesta de tokens y devuelve parámetros a la aplicación
El controlador de devolución de llamadas del lado del servidor obtiene el token de acceso desde la respuesta. El controlador de devolución de llamadas del lado del servidor y entonces devuelve el token de acceso y el estado al navegador, junto con datos de usuario, tokens y datos de sesión. Como mejor práctica, recomendamos que configure su servidor para almacenar el token de acceso, cree una sesión para la aplicación y devuelva la sesión a la aplicación, en vez de devolver el token de acceso. Como desarrollador, está al completo del control de la creación de la sesión, el almacenamiento del token de acceso y la gestión del estado de inicio de sesión, de modo que su implementación específica depende de usted.
A continuación se incluye un ejemplo de una respuesta satisfactoria en el registro de la consola del navegador.
{"success":true,"state":"https://MyExperienceCloudSite.my.site.com/","errMsg":null,"access_token":"00*******"}La aplicación procesa la respuesta del token y crea la sesión de usuario
La aplicación recibe la respuesta del token, la procesa y crea la sesión de usuario.
El usuario está registrado y realiza una acción en la aplicación
Su usuario está ahora registrado e inició sesión. Realiza una acción en su aplicación que requiere acceso a datos de Salesforce. Por ejemplo, hace clic en un botón para ver su historial de reserva de viajes, que se almacena en Salesforce.
La aplicación externa realiza una llamada autenticada a un extremo de Salesforce
Para acceder a los datos de Salesforce del usuario, su aplicación utiliza el token de acceso para realizar una llamada autenticada a un extremo de Salesforce protegido, como una API de Salesforce.
El usuario puede acceder a datos de Salesforce
El usuario puede ahora acceder a datos de Salesforce protegidos en su aplicación. Por ejemplo, puede ver su historial de reserva de viajes.
