Flujos de autorización OAuth

Nota La creación de aplicaciones conectadas está restringida a partir de Spring ‘26. Puede continuar utilizando aplicaciones conectadas existentes durante y después de Spring ‘26. Sin embargo, recomendamos utilizar aplicaciones cliente externas en su lugar. Si debe seguir creando aplicaciones conectadas, haga contacto con el Servicio de asistencia de Salesforce.

Consulte Las nuevas aplicaciones conectadas ya no se pueden crear en Spring ‘26 para obtener más detalles.

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 OAuth y aplicaciones conectadas

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

Nota Los usuarios pueden autorizar a una aplicación conectada a que acceda a datos protegidos más de una vez, como por ejemplo, un equipo portátil, uno de escritorio y un dispositivo móvil. El valor predeterminado es cinco autorizaciones por aplicación conectada y usuario. Si un usuario intenta otorgar acceso a una aplicación conectada después de alcanzar el límite de la organización, el token de acceso que no se utilizó por el periodo de tiempo más largo se revoca. Las aplicaciones conectadas más recientes de OAuth 2.0 que utilizan el flujo de servidor web están aprobadas para más dispositivos después de que el usuario otorgue el 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.

• 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 página web debe ser capaz de proteger la identidad de la aplicación conectada, definida por el Id. del 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.
• 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 conectada (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.
• 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.
• Aplicación conectada y terminología OAuth
  ¿Qué es un token? ¿Consumidor? ¿URL de devolución de llamada? Para comprender mejor las aplicaciones conectadas activadas por OAuth, familiarícese con algunos términos.