Acceso no-browser: la puerta de las integraciones en el perímetro

En el artículo anterior dejamos una pieza afuera a propósito. El mapa quedó así: Login Hours decide cuándo, Login IP Ranges decide desde dónde se puede entrar y Network Access decide quién se ahorra el desafío. Los tres responden bien una pregunta concreta: qué pasa cuando una persona abre un navegador y se loguea. La pieza que faltaba es IP Relaxation, y vive en las connected apps Salesforce.

El problema es que buena parte del tráfico que llega a tu org no se parece a eso. Cuando abrís la app móvil de Salesforce y ves los datos de tu org, no estás usando un navegador: estás usando una connected app. Lo mismo pasa con la integración que trae pedidos desde un sistema externo, con la herramienta de terceros que sincroniza contactos y con el proceso que corre de madrugada sin que nadie lo mire.

Este artículo trata sobre esa otra puerta. Cómo entran las integraciones, qué políticas las controlan y qué pasa con las reglas de red que ya configuraste cuando quien se conecta no es una persona frente a una pantalla.

Qué es una connected app Salesforce

Una connected app es un framework que permite que una aplicación de terceros se integre con Salesforce usando APIs y protocolos estándar: SAML, OAuth y OpenID Connect. Con esos protocolos, la connected app autentica, autoriza y da single sign-on a esas aplicaciones.

Pensala como una ficha. Esa ficha le dice a Salesforce qué protocolo usa la aplicación externa y dónde corre. Con esa información, Salesforce le da acceso a los datos y le adjunta políticas que restringen ese acceso, por ejemplo cuándo vence. Y el uso de cada connected app se puede auditar.

Las aplicaciones que se conectan así pueden correr en la propia plataforma, en otras plataformas, en otros dispositivos o como servicios SaaS. Salesforce agrupa los usos en cuatro casos principales:

Acceso a datos por API. La connected app pide acceso a los datos en nombre de una aplicación externa, mediante flujos de autorización OAuth. Es lo que permite trabajar en una aplicación y ver datos de otra.
Integración de service providers. Cuando Salesforce actúa como identity provider, la connected app integra otro servicio con SAML 2.0 u OpenID Connect.
Control de aplicaciones de terceros. El admin define qué datos puede ver una aplicación externa y quién puede usarla.
Autorización para API gateways externos. Salesforce funciona como servidor de autorización OAuth para proteger recursos alojados en otro lado.

Un dato de entrada: por defecto, los usuarios de tu org y de Experience Cloud pueden acceder a las connected apps instaladas en el org. Para esas apps, la puerta viene abierta. Lo que sigue en este artículo es cómo decidir quién pasa, desde dónde y por cuánto tiempo.

Y otro dato que cambia la lectura de todo lo que sigue: desde Spring ’26 ya no se pueden crear connected apps nuevas, salvo las que llegan con la instalación de un paquete. Las existentes siguen funcionando. Para lo nuevo, Salesforce recomienda External Client Apps, la próxima generación de connected apps. Este artículo explica las connected apps porque son las que ya están en tu org. Al final vemos qué implica el relevo.

Quién puede usar la app

La primera política es la más directa: quién tiene permitido usar la connected app. Se define en las políticas de acceso OAuth, en la sección Permitted Users, y tiene dos opciones.

La opción por defecto permite que cualquier usuario del org autorice la app después de loguearse. El usuario entra, la app le pide permiso y, si acepta, queda conectada.

La alternativa es Admin approved users are pre-authorized. Con esta opción, sólo acceden los usuarios que tienen asignado el perfil o el permission set asociado a la app, y lo hacen sin tener que autorizarla primero. El control pasa del usuario al admin.

El cambio entre una opción y otra no es inocuo. Cuando pasás a pre-autorizados, cualquiera que estuviera usando la app pierde el acceso, salvo que un permiso lo autorice de forma específica. Si hay una integración en producción, revisá antes quién la usa.

Hay un permiso que atraviesa todo esto: Use Any API Client. Un usuario que lo tiene puede acceder a cualquier connected app. La propia documentación pide cuidado al asignarlo. Es el equivalente a una llave maestra para las connected apps, y por eso merece la misma vigilancia que cualquier otro permiso de alto alcance.

Modificar los perfiles, los permission sets y los atributos SAML de una connected app requiere tres permisos combinados: Customize Application, Modify All Data y Manage Profiles and Permission Sets.

IP Relaxation: cuando el desde dónde no encaja

En el artículo anterior vimos que las restricciones de IP funcionan bien para un usuario sentado en la oficina. Con las connected apps Salesforce aparece un caso que esas reglas no resuelven solas.

El síntoma

Salesforce documenta un problema concreto: usuarios de la app móvil que tienen que verificar su identidad una y otra vez. La causa habitual, según la documentación, es que se loguean desde una dirección IP no autenticada. El caso aplica a orgs que tienen rangos confiables en Network Access o restricciones de IP a nivel perfil.

El org confía en ciertas direcciones, el celular llega desde otra y Salesforce hace lo que tiene que hacer: desconfiar.

El fundamento: por qué esa IP no es tuya

Para entender por qué pasa esto hay que salir un momento de Salesforce. A mi criterio, esta parte del problema se explica desde la infraestructura de redes, no desde la plataforma.

Muchos proveedores de internet usan CGNAT (Carrier-Grade NAT): una traducción de direcciones que permite que varios clientes compartan una misma IP pública. El estándar que define estos equipos lo dice sin rodeos: los suscriptores no reciben una IPv4 única.

Para un admin, eso tiene dos consecuencias. El equipo que hace la traducción está en la red del proveedor, y el suscriptor tiene poco o ningún control sobre él. Y la dirección que ve el servidor de destino ya fue traducida. Algunas IP públicas, además, son dinámicas: Cisco da el ejemplo de Starlink, cuyas direcciones no se pueden registrar por ese motivo.

Traducido al problema: la IP con la que llega esa conexión no pertenece al usuario ni a tu empresa. Pertenece al proveedor, y probablemente la comparten muchas otras personas. Agregarla a una lista de confianza sería confiar en todos los que la comparten. Y no agregarla deja al usuario frente a un desafío de verificación cada vez que entra.

La respuesta de Salesforce

IP Relaxation es la política de la connected app que decide qué hacer con las restricciones de IP del org cuando el acceso llega por esa app. Se puede aplicar a todas las apps cliente OAuth, incluidas las que usan OAuth y SAML para single sign-on. Tiene cuatro opciones:

Opción	Qué hace
Enforce IP restrictions	El usuario queda sujeto a las restricciones de IP del org, como los rangos de su perfil.
Enforce IP restrictions, but relax for refresh tokens	Aplica las restricciones, pero las relaja cuando la app usa un refresh token para obtener un access token nuevo.
Relax IP restrictions for activated devices	El usuario se salta las restricciones si se cumple alguna de dos condiciones.
Relax IP restrictions	El usuario no queda sujeto a ninguna restricción

La tercera opción merece detalle. La primera condición es que la app tenga una lista de rangos de IP permitidos y use el flujo OAuth web server; en ese caso, sólo pasan las solicitudes que vienen desde esas IP. Esos rangos se definen en la sección Trusted IP Range for OAuth Web Server Flow de la connected app. La segunda condición es que la app no tenga esa lista, use el flujo web server y el usuario complete la verificación de identidad cuando entra desde un navegador o dispositivo nuevo. Es decir: o la app llega desde un lugar conocido, o el usuario demuestra quién es.

Para el caso de la app móvil, la documentación ofrece dos caminos. Uno es relajar las restricciones de IP desde las políticas OAuth de la app, con la opción Relax IP restrictions. El otro es que los usuarios entren por el WiFi de la empresa o por VPN. Con la VPN, las IP de la VPN igual tienen que estar cargadas a nivel perfil. Si lo que querés es mantener las restricciones por perfil, la opción que corresponde es Enforce IP restrictions.

Tres reglas que cambian la lectura

La primera: las restricciones de IP sólo se aplican si están configuradas en el perfil del usuario. Si el perfil no tiene rangos, la política de la app no tiene nada que relajar ni que aplicar.

La segunda: los flujos SAML bearer assertion y JWT bearer token siempre aplican las restricciones de IP, sin importar lo que diga la política de la connected app. Para esas integraciones, IP Relaxation no existe.

La tercera: IP Relaxation no está soportado para connected apps que usan SSO con OpenID.

El costo de relajar

En el artículo anterior apareció el switch Enforce login IP ranges on every request. Acá vuelve. Si relajás las restricciones de IP en una connected app y el org tiene ese switch activado, hay casos en que el usuario no puede acceder a la app. Esto aplica a todas las connected apps con OAuth, incluidos los dispositivos móviles. Las connected apps con SAML no se ven afectadas, salvo que también tengan OAuth habilitado para single sign-on.

Con esa combinación, en las tres opciones que relajan, Salesforce bloquea por seguridad tres acciones: cambiar la contraseña, registrar un método de verificación y acceder a páginas de un login flow.

Ese es el precio de relajar. Con Relax IP restrictions, el usuario de esa app queda fuera de toda restricción de IP. Salesforce compensa limitando lo que se puede hacer desde una ubicación que no controla. Relajar no apaga la seguridad: la mueve de la red a otra capa, la identidad del usuario y las políticas de sesión.

Cuánto dura el acceso

Una vez que la app entró, la pregunta cambia. Ya no es quién ni desde dónde, sino por cuánto tiempo y cómo se corta.

La sesión de la app

Cada connected app puede tener su propio timeout de sesión. Si no se define, o se deja en None, que es el valor por defecto, Salesforce usa el timeout del perfil del usuario.

También se puede exigir una sesión de alta seguridad (High Assurance) para la app. Acá hay un detalle que rompe integraciones. Sólo los flujos de autorización que incluyen un paso de aprobación del usuario soportan logins de API con sesión High Assurance. En los flujos sin ese paso, esos logins se bloquean.

Los refresh tokens

Cuando la app necesita un access token nuevo, lo obtiene con un refresh token. La Refresh Token Policy define cuánto tiempo vale ese refresh token. Tiene cuatro opciones:

Valid until revoked: el token se usa indefinidamente, salvo que lo revoque el usuario o el admin. Fue la opción por defecto.
Immediately expire: el token es inválido de inmediato.
Expire if not used for n: vale mientras se haya usado dentro del plazo definido.
Expire after n: vale por un plazo fijo.

Ese default ya no funciona igual. Salesforce ahora exige un límite de 30 días de inactividad para los refresh tokens. Funciona como una ventana deslizante: cada vez que el token se usa, el plazo vuelve a empezar. Si pasa 30 días sin usarse, vence, y Salesforce revoca también el access token asociado. La app o el usuario tienen que pedir acceso de nuevo.

Con ese límite aplicado, Valid until revoked deja de ser válida. En la UI, la opción desaparece y la política pasa a Expire if not used for, con 30 días. Las demás opciones conviven con el límite. Expire after n respeta su plazo, pero un token inactivo vence igual a los 30 días. Immediately expire no cambia.

Salesforce aplica este control a las connected apps. Si en tu org ya está aplicado, la opción aparece bloqueada y no se puede editar.

La consecuencia práctica: una integración que nadie usa durante un mes pierde el acceso hasta que lo vuelva a pedir.

Existe además Single Logout: cierra la sesión en la app cuando el usuario sale de Salesforce.

Revocar y bloquear

Desde la página Connected Apps OAuth Usage, el admin ve las conexiones OAuth actuales. Para apps no instaladas, también ve los intentos de uso que Salesforce denegó automáticamente.

Ahí hay dos acciones que se parecen, pero no hacen lo mismo:

Revoke All termina todas las sesiones actuales de la app.
Block termina las sesiones actuales y además impide sesiones nuevas hasta que se haga Unblock.

Revocar corta lo que está pasando. Bloquear corta también lo que podría pasar. La misma acción aparece en las políticas de sesión de la app como Block this application, que deja la app inaccesible para los usuarios del org.

El usuario también tiene control. Puede ver información de cada app que autorizó y revocarle el acceso, y desde ese momento la app no puede acceder más a sus datos. Cada connected app admite cinco aprobaciones por usuario: con la sexta, se revoca la más vieja.

Un último dato que explica más de un ticket: las sesiones de connected apps pueden expirar cuando entra en vigor un release mayor de Salesforce.

Integraciones y MFA: qué flujos quedan alcanzados

En el artículo sobre autenticación vimos el enforcement de MFA. La pregunta natural acá es si alcanza también a las integraciones.

La respuesta depende del flujo. El enforcement apunta sólo a los logins de UI de empleados. Pero hay flujos OAuth que pasan por la UI. Las Connected Apps o External Client Apps que usan los flujos Web Server o Hybrid Token requieren que el usuario se loguee en la UI de Salesforce, así que quedan alcanzadas. Las que usan JWT Bearer o Client Credentials no se ven afectadas, porque en esos flujos no hay login de UI.

Esa distinción es la que define si una integración se rompe o no. Antes de que te sorprenda, averiguá qué flujo usa cada connected app de tu org.

Que el enforcement no alcance a los logins por API no significa que ahí no se pueda pedir MFA. Existe un permiso específico, Multi-Factor Authentication for API Logins, que exige un segundo desafío para acceder a las APIs. Para que funcione, el usuario primero completa MFA en la UI. Después usa los códigos de su app autenticadora en los logins por API. Los usuarios API Only pueden entrar a la UI sólo para registrar su método de MFA, y después pierden ese acceso.

Lo mismo vale para las automatizaciones de testing: si usan logins de UI, pueden necesitar cambios.

Un control que bloquea: VPN anonimizadoras y proxies

En el artículo anterior separamos los controles que desafían de los que bloquean. Hay uno más que entra en la segunda categoría, y que apunta directo a las integraciones.

Salesforce aplica medidas reforzadas contra conexiones desde VPN anonimizadoras, proxies e IPs de alto riesgo desde el 20 de noviembre de 2025. Desde el 24 de abril de 2026, esas medidas incluyen todo el tráfico de Connected Apps y de API.

La respuesta no es un desafío de verificación. El usuario afectado queda congelado y con el acceso bloqueado. Además, se revocan todos los refresh tokens OAuth que tenía otorgados. La contención se aplica apenas se detecta el uso indebido, así que el usuario puede perder el acceso antes de que el admin lea el aviso.

Ese aviso es un email titulado «Salesforce Security notification» que llega a los Security Contacts y al usuario afectado. Si el org no tiene Security Contact, el aviso va a todos los admins y usuarios del instance afectado que tengan Modify All Data. Si todavía no definiste Security Contacts, este es un buen motivo.

Recuperar el acceso implica revisar si la actividad es normal para ese usuario, descongelar la cuenta y pedirle que se reautentique y cambie la contraseña. Como la contención revocó los refresh tokens, además tiene que volver a autorizar sus connected apps.

Lo que más importa es que el usuario deje de conectarse desde esas redes. Si sigue usándolas, la contención se repite. Y si el único admin del org es el que quedó bloqueado, la salida es Soporte.

El relevo ya empezó: External Client Apps

Todo lo anterior describe las connected apps. Pero, como vimos al principio, el reemplazo ya está en marcha.

Las External Client Apps son la próxima generación de connected apps. Usan SAML y OAuth y dan single sign-on, igual que las connected apps. La diferencia está en la estructura: son totalmente compatibles con metadata, permiten separar roles de usuario y admiten packaging de segunda generación. El framework de connected apps no permite separar esos roles y es difícil de empaquetar. Según Salesforce, las External Client Apps ofrecen buena parte de esas funciones con más seguridad.

Desde Spring ’26 se deshabilitó la creación de connected apps nuevas. El bloqueo aplica por API y por UI, con una excepción: la instalación de paquetes. Las connected apps existentes siguen funcionando, y editarlas, instalarlas o borrarlas no cambia. Por ahora se puede pedir a Soporte que habilite la creación, pero en releases futuros esa vía desaparece.

Salesforce anunció que comunicará el fin de soporte de las connected apps existentes, todavía sin fecha. Su recomendación es usar External Client Apps en todos los casos y migrar las connected apps locales. Esa migración conviene hacerla antes de que llegue el fin de soporte. Hay un matiz: algunas funciones todavía sólo existen en connected apps. Y las fechas, como siempre, pueden cambiar.

¿Significa que todo lo de este artículo queda viejo? No. Las External Client Apps tienen las mismas políticas que vimos acá: OAuth access policies, IP Relaxation, Trusted IP Range for OAuth Web Server Flow, políticas de sesión y gestión del uso de OAuth. Las diferencias están en los bordes. User provisioning sigue siendo exclusivo de las connected apps, y el flujo username-password no va a estar disponible para External Client Apps.

Lo que queda para el próximo artículo

Las connected apps cierran la pregunta de cómo entran las integraciones. Quién puede usarlas lo decide Permitted Users. Desde dónde, IP Relaxation, con reglas que hay que conocer antes de tocar. Cuánto dura, el timeout de la app y la Refresh Token Policy. Y cuando hace falta cortar, Revoke All corta lo actual y Block corta también lo que viene.

Hay un hilo que atravesó todo el artículo: la sesión. El timeout de la app cae al del perfil, y High Assurance es un nivel de sesión. Relajar la IP traslada el control a la sesión. El próximo artículo trata justamente de eso: qué pasa cuando ya estás adentro.

Para seguir profundizando

Si querés profundizar en este tema, podés consultar la documentación oficial de Salesforce.

Fuentes técnicas complementarias

Configure CGNAT (Carrier-Grade NAT) IPs — Cisco, documento 225267
RFC 6888: Common Requirements for Carrier-Grade NATs (CGNs) — IETF, BCP 127