Diagrama y proceso de flujo de intercambio de tokens

Este es el escenario: Aloja un portal de clientes fuera de Salesforce Platform. Para asegurarse de que los clientes pueden acceder a toda la información que necesitan, integró el portal con una variedad de aplicaciones y microservicios diferentes. Por ejemplo, utiliza una aplicación externa para gestionar pagos y envíos, y utiliza Amazon Web Services para gestionar datos de clientes. No desea hacer que los clientes inicien sesión en todos estos servicios diferentes, por lo que también utiliza Okta como proveedor de identidad externo. De este modo, los clientes pueden iniciar sesión en Okta y acceder a toda la información que necesitan en su portal.

Necesita una forma de gestionar casos de asistencia en el portal y sabe que Salesforce puede hacer el trabajo. Sin embargo, desea asegurarse de que los clientes pueden acceder a su información de caso directamente en su portal sin iniciar sesión en Salesforce. En otras palabras, desea una forma de hacer que Salesforce se ajuste a su sistema existente. Ahí es donde entra el flujo de intercambio de tokens. Con este flujo, puede asegurarse de que los clientes pueden acceder a sus datos de Salesforce cuando inician sesión en su portal a través de Okta.

Para comprender cómo el flujo de intercambio de tokens puede proporcionar esta experiencia, echemos un vistazo a la secuencia del flujo. Para obtener una explicación más detallada de las solicitudes y respuestas en este flujo, consulte Configurar el flujo de intercambio de tokens.

Cuando se inicie el flujo, suponga que el usuario final ya inició sesión en el portal de clientes (el cliente) a través de Okta (el proveedor de identidad). El cliente se integra con Salesforce utilizando el marco de trabajo de la aplicación cliente externa.

• (1) El usuario final solicita acceso a recursos protegidos de Salesforce. Por ejemplo, en el portal de clientes, el usuario hace clic en un botón para acceder a la información de su caso de asistencia.
• (2) Como el usuario ya inició sesión, el cliente tiene un token válido del proveedor de identidad.
• (3) La aplicación cliente envía una solicitud POST al extremo Salesforce /services/oauth2/token. Esta solicitud incluye múltiples parámetros, que dependen de su caso de uso. Como mínimo, debe incluir estos parámetros.
  • Un parámetro grant_type, que indica a Salesforce que esta aplicación desea utilizar el flujo de intercambio de tokens.
  • Un parámetro de subject_token con el token del proveedor de identidad.
  • Un parámetro subject_token_type, que indica el tipo de token, como un token de acceso opaco, un token de actualización, un token de Id., una afirmación SAML o un token web JSON (JWT).
  • Un client_id, que indica a Salesforce qué aplicación cliente externa está registrada para este cliente.
• (4) El tiempo de ejecución de Salesforce OAuth recibe la solicitud POST y la valida. Si la solicitud es válida, Salesforce pasa el token del proveedor de identidad a un controlador de intercambio de tokens Apex.
• (5) El controlador de intercambio de tokens Apex valida el token. Como parte de su validación, el controlador puede llamar al proveedor de identidad.
  

  Nota Esta llamada al proveedor de identidad es opcional y depende de cómo desarrolle su controlador. Si no incluye esta llamada, el flujo continúa al paso 7.
• (6) (Opcional) Si se llama, el proveedor de identidad devuelve información para ayudar al controlador a validar el token.
• (7) El gestor asigna el asunto del token a un asunto de Salesforce. Para obtener más información acerca del asunto, el controlador puede volver a llamar al proveedor de identidad.
  

  Nota Esta segunda llamada al proveedor de identidad también es opcional. Si no incluye esta llamada, el flujo continúa al paso 9.
• (8) (Opcional) Si se llama, el proveedor de identidad devuelve información de usuario al controlador de intercambio de tokens.
• (9) Si el gestor encuentra un usuario existente de Salesforce, devuelve un usuario. Si no puede encontrar un usuario existente, configura un nuevo objeto Usuario y lo devuelve a Salesforce para su inserción automatizada.
• (10) El tiempo de ejecución de Salesforce OAuth comprueba si el controlador devolvió un usuario existente. De lo contrario, Salesforce inserta un nuevo usuario en nombre del controlador de intercambio de tokens.
• (11) El tiempo de ejecución de Salesforce OAuth devuelve un token de acceso al cliente. La respuesta del token también incluye cualquier otro token y parámetro solicitado, como un token de actualización o un token de Id.
• (12) El cliente recibe la respuesta del token con el token de acceso y otros tokens solicitados.
• (13) (Opcional) Si es necesario, el cliente puede llamar al extremo de información de usuario de Salesforce para obtener más información acerca del usuario y completar el inicio de sesión.
• (14) El cliente ahora puede utilizar el token de acceso para realizar una solicitud autenticada a un extremo protegido de Salesforce.
• (15) Salesforce otorga acceso a los recursos solicitados.

Al final del flujo, el usuario final puede iniciar sesión a través del proveedor de identidad y acceder a sus datos de Salesforce en la aplicación cliente, sin iniciar sesión directamente en Salesforce. Por ejemplo, pueden iniciar sesión a través de Okta y acceder a su información de casos de asistencia, proporcionada por Salesforce, en su portal de clientes.