Flujos de autorización OAuth

Por ejemplo, cuando abre la aplicación móvil Salesforce para acceder a sus datos de Salesforce, inicia un flujo de autorización de OAuth 2.0. En este flujo, su organización de Salesforce es el servidor de recursos que aloja el recurso protegido. La aplicación móvil Salesforce es el cliente que solicita acceso. Usted es el propietario del recurso, que permite a la aplicación móvil Salesforce acceder y gestionar sus datos de Salesforce por Internet en cualquier momento. Su organización de Salesforce, actuando como el servidor de autorización, otorga acceso a la aplicación móvil Salesforce emitiendo un token de acceso. Pasemos por el flujo paso a paso.

1. Abre la aplicación móvil Salesforce.
2. Se muestra una solicitud de autenticación, donde ingresa su nombre de usuario y contraseña.
3. La aplicación móvil Salesforce envía sus credenciales a Salesforce e inicia el flujo de autorización de OAuth.
4. Salesforce envía a la aplicación móvil tokens de acceso y actualización como confirmación de una validación correcta del usuario y la aplicación móvil.
5. Usted aprueba la solicitud para otorgar acceso a la aplicación móvil Salesforce.
6. La aplicación móvil Salesforce se inicia.

Después de este flujo inicial, la aplicación móvil Salesforce se inicia inmediatamente cuando la sesión está activa. Si la sesión está inactiva, la aplicación móvil Salesforce utiliza el token de actualización procedente de su autorización inicial para obtener una sesión actualizada.

Contraste este enfoque con dar su nombre de usuario y contraseña a una aplicación cliente para acceder a un servidor de recursos en su nombre. La aplicación cliente le representa de forma efectiva, con el mismo acceso a sus datos precisamente. Si deja de confiar en la aplicación cliente, debe cambiar su contraseña en el servidor de recursos, lo que supone un inconveniente y un riesgo de seguridad. Por este motivo, la autorización OAuth es una solución mejor.

Flujos de autorización de OAuth y aplicaciones cliente externas

Todos los flujos de autorización de OAuth, excepto el flujo Afirmación SAML, requieren que defina una aplicación cliente externa. El marco de trabajo de la aplicación cliente externa permite que una aplicación externa se integre con Salesforce utilizando API y protocolos estándar, como SAML, OAuth y OpenID Connect. Las aplicaciones cliente externas utilizan estos protocolos para autenticar, autorizar e integrar aplicaciones externas y proveedores de servicio. Las aplicaciones externas integradas con Salesforce pueden ejecutarse en la plataforma de éxito de clientes, dispositivos, suscripciones SaaS u otras plataformas. En el ejemplo anterior, la aplicación móvil Salesforce se integra con su organización utilizando una aplicación cliente externa.

Nota Los usuarios pueden autorizar a una aplicación cliente externa a acceder a datos protegidos más de una vez, por ejemplo, un portátil, un equipo de escritorio y un dispositivo móvil. El valor predeterminado es cinco autorizaciones por aplicación cliente externa por usuario. Si un usuario intenta otorgar acceso a una aplicación cliente externa tras alcanzar el límite de la organización, se revoca el token de acceso que no se utilizó durante el periodo de tiempo más largo. Las aplicaciones cliente externas de OAuth 2.0 más recientes que utilizan el flujo de servidor web se aprueban para más dispositivos después de que el usuario otorgue acceso. El flujo de usuario-agente requiere la aprobación del usuario cada vez que se aplica.

Casos de uso de flujos de autorización OAuth

Como desarrollador de Salesforce, puede elegir entre varios flujos de autorización OAuth. Cuando selecciona el flujo correcto para su aplicación, tenga en cuenta estos casos de uso.

Importante Algunos flujos tienen consideraciones de seguridad importantes. Por ejemplo, cuando se utiliza un flujo de servidor web, debe almacenar el secreto de cliente de forma segura. Recomendamos evitar los flujos usuario-agente y nombre de usuario-contraseña porque transmiten credenciales. En su lugar, seleccione un flujo que libere a la aplicación de tener que gestionar, almacenar y proteger credenciales.

• Flujos de identidad desatendida
  Puede utilizar las API de identidad desatendida para configurar el inicio de sesión, el registro, el inicio de sesión sin contraseña y mucho más para una aplicación sin plataforma. Los flujos de Identidad desatendida solo están disponibles para usuarios externos, también conocidos como clientes y socios.
• Crear una experiencia de inicio de sesión único nativa en su aplicación
  Con un parámetro opcional en el flujo de servidor web de OAuth 2.0 y un flujo de usuario-agente, puede crear una experiencia de inicio de sesión único (SSO) que se parece que su aplicación externa está integrada con un proveedor de identidad externo. Con este proceso, vincula un flujo de OAuth a un flujo de SSO mientras mantiene el control de la experiencia dentro de su aplicación. Este parámetro es compatible con sitios de Experience Cloud, de modo que puede utilizar esta función para agregar SSO a una implementación de Identidad desatendida. Este parámetro también es compatible con Mi dominio.
• Flujo servidor web de OAuth 2.0 para la integración de aplicaciones web
  Para integrar una aplicación web externa con la API de Salesforce, utilice el flujo servidor web de OAuth 2.0, que implementa el tipo de otorgamiento de código de autorización de OAuth 2.0. Con este flujo, el servidor que aloja la aplicación web debe poder proteger la identidad de la aplicación cliente externa, definida por el Id. de cliente y el secreto de cliente.
• Flujo de agente de usuario OAuth 2.0 para la integración de escritorio o de aplicación móvil
  Con el flujo usuario-agente de OAuth 2.0, los usuarios autorizan a una aplicación de escritorio o móvil para acceder a datos empleando un navegador externo o integrado. Las aplicaciones que se ejecutan en un navegador utilizando un lenguaje de secuencias de comandos como JavaScript también utilizan este flujo. Este flujo utiliza un tipo de otorgamiento implícito de OAuth 2.0.
• Flujo de token de actualización de OAuth 2.0 para sesiones renovadas
  El flujo del token de actualización de OAuth 2.0 renueva los tokens de acceso emitidos por el flujo de servidor web de OAuth 2.0 o el flujo de usuario-agente de OAuth 2.0.
• Flujo de intercambio de tokens de OAuth 2.0
  Cuando Salesforce es solo un componente de una arquitectura que incluye un proveedor de identidad central junto con múltiples aplicaciones y microservicios, utilice el flujo de intercambio de tokens de OAuth 2.0 para simplificar sus patrones de integración. Con este flujo, intercambie tokens desde proveedores de identidad externa para tokens de Salesforce y otorgue acceso a datos de Salesforce.
• Autorización de OAuth 2.0 y Gestión de sesión para aplicaciones híbridas
  La gestión de sesiones web para aplicaciones híbridas es compleja con un flujo de token de actualización o usuario-agente típico. En estos flujos, una aplicación híbrida establece cookies de dominio solicitadas y acorta un token de acceso en una sesión web. Pero el token de acceso y la sesión web no están conectados en estos flujos. En su lugar, debe realizar un seguimiento cuando los tokens de acceso y actualización caducan y cuando caduca la sesión web, y luego volver a unir manualmente la sesión para evitar servicios interrumpidos. Para evitar este proceso complejo, utilice los flujos de aplicación híbrida de OAuth 2.0. Estos flujos conectan los tokens de acceso y actualización con la sesión web para proporcionar a aplicaciones híbridas gestión de sesión web directa.
• Flujo de soporte JWT de OAuth 2.0 para la integración de servidor a servidor
  En algunos casos desea autorizar a servidores para acceder a los datos sin tener que iniciar sesión de forma interactiva cada vez que los servidores intercambian información. Para estos casos, puede utilizar el flujo del token de soporte JWT de OAuth 2.0. Este flujo utiliza un certificado para firmar la solicitud JWT y no requiere una interacción de usuario explícita. No obstante, este flujo requiere aprobación previa de la aplicación cliente.
• Flujo de credenciales de cliente de OAuth 2.0 para la integración de servidor a servidor
  En ocasiones, desea compartir directamente información entre dos aplicaciones sin molestar a un usuario. Para estos escenarios, puede utilizar el flujo de credenciales de cliente de OAuth 2.0. En este flujo, la aplicación cliente intercambia sus credenciales de cliente definidas en la aplicación cliente externa (su clave de consumidor y secreto de consumidor) para un token de acceso. Este flujo elimina la necesidad de interacción de usuario explícita, aunque le requiere especificar un usuario de integración para ejecutar la integración. Puede utilizar este flujo como una alternativa más segura al flujo de nombre de usuario-contraseña de OAuth 2.0.
• Registro de cliente dinámico de OpenID Connect para pasarelas de API externas
  Aunque no es un flujo de autorización típico, puede utilizar un registro de cliente dinámico de OpenID Connect para habilitar su instancia de Salesforce como un servidor de autorización de OAuth independiente para proteger recursos alojados en una pasarela de API externa.
• Generar un token de acceso inicial
  El registro de cliente dinámico de OpenID Connect permite a los clientes de OAuth 2.0 (aplicaciones conectadas) registrar directamente aplicaciones conectadas con Salesforce. Para autenticar estas solicitudes de registro de cliente, Salesforce requiere un token de acceso inicial.
• Introspección de token de OpenID Connect
  Como parte del proceso de autorización, la introspección de tokens permite a todas las aplicaciones conectadas de OAuth comprobar el estado actual de un token de acceso o actualización de OAuth 2.0. El servidor de recursos o las aplicaciones conectadas envían el Id. de cliente y el secreto de la aplicación cliente al servidor de autorización, iniciando un flujo de autorización de OAuth. Como parte de este flujo, el servidor de autorización valida o realiza una introspección del token de acceso de la aplicación cliente. Si el token de acceso es vigente y válido, se otorga acceso a la aplicación cliente.
• Flujo de dispositivos de OAuth 2.0 para la integración de IoT
  Para integrar aplicaciones que se ejecutan en dispositivos con funciones de ingreso o visualización limitadas, como Smart TVs, electrodomésticos y otros dispositivos IoT, utilice el flujo de dispositivos de OAuth 2.0. Las aplicaciones de línea de comandos también pueden utilizar este flujo. Los usuarios pueden conectar estas aplicaciones con Salesforce accediendo a un navegador en un dispositivo con capacidades de entrada más avanzadas, como una computadora de escritorio o un dispositivo móvil.
• Flujo de tokens de activos de OAuth 2.0 para asegurar dispositivos conectados
  Para integrar dispositivos IoT con la API de Salesforce, utilice el flujo de tokens de activos de OAuth 2.0. Los tokens de activos son un token de autenticación JWT basado en estándares abiertos para la verificación y protección de solicitudes desde dispositivos conectados. Los tokens de activos identifican el dispositivo en un servicio backend que procesa la transmisión de datos y eventos desde el dispositivo. Estos tokens permiten el registro de datos del dispositivo con la plataforma Salesforce y su vinculación del dispositivo con datos de Salesforce CRM acerca del cliente, cuenta o contacto.
• Demostración de flujo de token de activos
  Para una demostración rápida de tokens de acceso, puede utilizar la aplicación de demostración Asset Token Explorer. La aplicación de demostración simplifica su experiencia inicial de obtener un token de acceso e intercambiarlo por el token de activos.
• Flujo nombre de usuario-contraseña de OAuth 2.0 para escenarios especiales
  Puede utilizar el flujo nombre de usuario-contraseña para autorizar a un cliente a través de una aplicación conectada que ya tiene las credenciales del usuario. No obstante, recomendamos evitar este flujo porque pasa las credenciales en ambas direcciones. Utilícelo únicamente si hay un alto grado de confianza entre el propietario del recurso y el cliente, el cliente es una aplicación propia, Salesforce está alojando los datos y no hay otros tipos de otorgamiento disponibles. En estos casos, establezca los permisos de usuario para minimizar el acceso y proteger las credenciales almacenadas contra el acceso no autorizado.
• Bloquear flujos de autorización para mejorar la seguridad
  Los flujos usuario-agente y nombre de usuario-contraseña de OAuth 2.0 se consideran inseguros y no se recomiendan. Para tener mayor seguridad, recomendamos que bloquee estos flujos en Salesforce para evitar que los desarrolladores los utilicen para crear nuevas integraciones. Si su organización se creó en Summer ‘23 o posteriores, el flujo de contraseña de nombre de usuario-contraseña está bloqueado de manera predeterminada. Puede activar el flujo de nombre de usuario-contraseña si es necesario. Si tiene integraciones existentes que utilizan el flujo usuario-agente o nombre de usuario-contraseña, actualícelas a un flujo de OAuth 2.0 más seguro. También puede bloquear el flujo Código de autorización y credenciales que se utiliza para configurar de forma segura un proceso de inicio de sesión desatendido. También puede bloquear ciertos flujos que no utilizan la extensión PKCE.
• Flujo de afirmación de soporte SAML de OAuth 2.0 para aplicaciones autorizadas previamente
  Con el flujo de afirmación de soporte SAML de OAuth 2.0, un cliente (a través de una aplicación conectada) puede utilizar autorización previa suministrando una afirmación SAML 2.0 firmada para solicitar un token de acceso OAuth. La firma digital aplicada a la afirmación SAML autentica la aplicación autorizada. Una afirmación de SAML es un token de seguridad XML emitido por un proveedor de identidad y consumido por un proveedor de servicio. El proveedor de servicio se basa en su contenido para identificar al asunto de la afirmación para fines relacionados con la seguridad.
• Flujo de afirmación SAML para acceder a la API
  El flujo de afirmación SAML es una alternativa para las organizaciones que utilizan SAML para acceder a Salesforce y desean acceder a la API de la misma forma. Los clientes pueden federarse con la API mediante la afirmación SAML, de las misma forma que se federan con Salesforce para el inicio de sesión único Web. Puede utilizar este flujo de afirmación sin una aplicación conectada.
• Errores de autorización de OAuth 2.0
  Se pueden producir errores durante la autorización de OAuth. Por ejemplo, un usuario deniega el acceso a la aplicación conectada o los parámetros de la solicitud son incorrectos. Cuando se producen errores, el servidor que autoriza envía un error a la URL de devolución de llamada con un código de error.
• Flujo de OAuth 1.0.A
  Si su organización utiliza el protocolo OAuth 1.0.A, utilice este flujo de autorización para integrar un cliente (a través de una aplicación conectada) con la API de Salesforce.
• Códigos de error de OAuth 1.0.A
  Se pueden producir errores durante la autorización. Por ejemplo, la dirección URL de devolución de llamada no es válida. Cuando se producen errores durante el flujo de OAuth 1.0.A, Salesforce devuelve un código de error.