API de identidad desatendida: Flujo de registro desatendido para clientes públicos
Para aplicaciones que pueden mantener información confidencial, como aplicaciones con una sola página, 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 contenido de ayuda describe cómo configurar el flujo y cómo funciona. Para configurar una implementación de ejemplo de extremo a extremo, consulte la Guía de implementación de Identidad desatendida.
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. Cree una aplicación web de una única página y configure el flujo 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.
Por motivos de seguridad, recomendamos encarecidamente que implemente la extensión Proof Key for Code Exchange (PKCE) para este flujo.
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 necesarios y las políticas de acceso 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 el 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. Nuevamente, depende de usted el aspecto que desee que tenga este formulario. (6)
- El usuario recibe su OTP y la 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. La solicitud incluye la OTP y el 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. Si el flujo se ejecuta en el navegador, el redireccionamiento 302 se procesa en el navegador y la respuesta se entrega de forma desatendida al extremo de devolución de llamada. (1)
- Su extremo de devolución de llamada extrae el código y otros parámetros del redireccionamiento 302. Devuelve esta información a su aplicación. (11)
- Su aplicación inicia el intercambio de códigos a través de una solicitud POST al extremo del token. (12)
- Desde el extremo del token, Salesforce devuelve una respuesta de token de acceso a su aplicación. (13)
- Su aplicación procesa la respuesta del token y crea la sesión del usuario. (14)
- El usuario ahora está registrado e inició sesión. 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)
Este flujo requiere un extremo del lado del servidor que pueda gestionar el redireccionamiento 302 y devolver el código de autorización y otros parámetros a su aplicación. Para implementaciones donde completa el intercambio de códigos en su navegador, puede utilizar el extremo /services/oauth2/echo. Este extremo analiza automáticamente el redireccionamiento 302, extrae los parámetros y los devuelve a su aplicación en formato JSON. Utilizamos /services/oauth2/echo en los ejemplos de código para este flujo. Para obtener más información, consulte Extremo Echo OAuth 2.0.
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 desatendida al extremo de registro desatendido (/services/auth/headless/init/registration) en su sitio de Experience Cloud utilizando Java asíncrono y XML (AJAX).
Puede incluir este encabezado en su solicitud de registro.
| 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/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, debe generarla automáticamente y pasarla en el parámetro userdata. |
Contiene toda la información de usuario obligatoria. Como mínimo, Salesforce requiere 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 que desea utilizar para verificar la identidad del usuario. Salesforce admite dos valores para el método de verificación: email y sms. |
customdata
|
No. | Un objeto JSON que contiene cualquier información de usuario personalizada que recopile. Por ejemplo, puede incluir la dirección de calle del usuario. Usted determina la estructura de este objeto. Se entrega al controlador de registro como una cadena JSON, que puede retirar el número de serie en cualquier estructura de clase de Apex que desee. |
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.
POST /services/auth/headless/init/registration? HTTP 1.1
Host: MyExperienceCloudSiteName.my.site.com
Content-Type: application/json
{
“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 aún tiene que verificar la identidad del usuario, no hace nada con la información del usuario. En su lugar, Salesforce pone esta información en cola para su procesamiento posterior.
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í en el formato |
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 del cuerpo verificationmethod desde 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 usuarios invitados desatendido en su aplicació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í. | |
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. Para este flujo, puede utilizar el extremo de echo, https://MyExperienceCloudSite.my.site.com/services/oauth2/echo, como su extremo de devolución de llamada. |
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 UVID en el cuerpo de la solicitud, también puede pasarla 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 genera y gestiona completamente por su aplicación. 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 usuarios invitados desatendido en su aplicación. |
code_challenge
|
Solo si está utilizando PKCE. PKCE se recomienda, especialmente para aplicaciones de una única página. | Obligatorio si se utiliza la extensión PKCE. Especifica el valor de hash SHA256 del valor Este parámetro se requiere si se especifica
|
A continuación se incluye un ejemplo de solicitud al extremo de autorización. Este ejemplo incluye PKCE.
POST /services/oauth2/authorize? HTTP 1.1
Host: MyExperienceCloudSiteName.my.site.com
Auth-Request-Type: user-registration
Auth-Verification-Type: email
Authorization: Basic <base64-encoded request ID:OTP>
reponse_type=code_credentials&
client_id=******&
redirect_uri=https://www.MyExperienceCloudSite.my.site.com/services/oauth2/echon&
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 valida las credenciales y devuelve un redireccionamiento 302 al extremo de devolución de llamadas
Salesforce devuelve un redireccionamiento HTTP 302 a una URL preconfigurada que contiene el código de autorización. Si el flujo se produce en el navegador, se procesa el redireccionamiento 302 en el navegador. A continuación, Salesforce envía automáticamente la respuesta de redireccionamiento a la URL de redireccionamiento, que apunta al extremo de devolución de llamada /services/oauth2/echo en estos ejemplos de código. Durante este proceso, el navegador no se redirige, todo sucede en segundo plano.
A continuación se incluye una URL de ejemplo que recibe el extremo de devolución de llamadas echo.
https://MyExperienceCloudSite.my.site.com/services/oauth2/echo?code=aPrxr*******%3D%3D&state=mystate&sfdc_community_url=https%3A%2F%2FMyExperienceCloudSite.my.site.com%&sfdc_community_id=0DBRXXXXXXXXXEl extremo de devolución de llamadas extrae el código y lo devuelve a la aplicación
El extremo de devolución de llamada extrae el código de autorización y otros datos y envía esta información de vuelta a su aplicación. A continuación se incluye un ejemplo de la respuesta JSON procedente del extremo de echo.
{"code":"aPrxr*******",
"sfdc_community_url":"https://MyExperienceCloudSite.my.site.com",
"sfdc_community_id":"0DBRXXXXXXXXX",
"state":"mystate"}La aplicación recibe la respuesta del código y realiza el intercambio de códigos
El navegador recibe la respuesta de código. 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/","sfdc_community_url":"https://MyExperienceCloudSite.my.site.com/vforcesite","sfdc_community_id":"0DBxxxxxxxxxxxx","errMsg":null,"code":"aPrxC1*******"}El navegador solicita desatendidamente que intercambie el código para un token de acceso.
Para evitar exponer el secreto de consumidor al navegador, debe desactivar los parámetros Requerir secreto para flujo de servidor web y Requerir secreto para flujo de token de actualización en su aplicación conectada o aplicación cliente externa. Con esta configuración desactivada, no se requiere el secreto de consumidor en la solicitud de autorización. Si es posible, recomendamos que realice el intercambio de códigos utilizando un backend de servidor. Consulte las API de Identidad desatendida: Flujo Código de autorización y credenciales para clientes privados.
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
|
No. | 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
|
Solo si está utilizando PKCE. Recomendamos que siempre utilice PKCE cuando utilice este flujo para aplicaciones de una única página. | Especifica 128 bytes de datos aleatorios con alta entropía para hacer que sea difícil adivinar el valor
|
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. De lo contrario, la aprobación falla. Para este flujo, puede utilizar el extremo de echo, https://MyExperienceCloudSite.my.site.com/services/oauth2/echo, como su extremo de devolución de llamada. |
A continuación se incluye una solicitud de token de ejemplo.
POST /services/oauth2/token? HTTP 1.1
Host: MyExperienceCloudSiteName.my.site.com
grant_type=authorization_code&
code=aPrxC1*******&
client_id=******&
redirect_uri=https://www.MyExperienceCloudSite.my.site.com//services/oauth2/echo&
code_verifier=Y29kZ*******
Salesforce otorga un token de acceso
Después de validar las credenciales de la aplicación, Salesforce devuelve un token de acceso al navegador. A continuación se incluye un ejemplo de respuesta de token de acceso en formato JSON.
{
"access_token":"*******************",
"sfdc_community_url":"https://MyExperienceCloudSiteName.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 solo se devuelve 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 URL de identidad no cambió 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 está incluido en la cadena de consulta original. |
token_type
|
Sí. | Un tipo de token Bearer, que se utiliza para todas las respuestas que influyen un token de acceso. |
La aplicación procesa la respuesta del token y crea la sesión de usuario
El navegador almacena la información de la respuesta del token y crea la sesión de usuario. En este punto, el usuario ha iniciado sesión y su aplicación llama al extremo de información de usuario de Salesforce para confirmar que el inicio de sesión se realizó correctamente.
El usuario está registrado y realiza una acción en la aplicación
Su usuario está ahora completamente 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. Desde la perspectiva del usuario, el proceso completo desde el inicio de sesión hasta el acceso a sus datos se produjo sin requerir nunca salir de la aplicación.
