OAuth

OAuth (Open Authorization) es un estándar abierto de autorización que permite que una aplicación acceda a recursos de otra en nombre del usuario, sin que este tenga que entregar su contraseña. La versión vigente es OAuth 2.0 y es la base de los botones de tipo "Iniciar sesión con Google" y de casi toda integración entre sistemas modernos.

La idea central es la delegación de permisos: en lugar de compartir tu clave, le das a la app un token de acceso que representa un permiso limitado (por ejemplo, "leer tus contactos") y con vencimiento. Ese token se puede revocar en cualquier momento sin cambiar tu contraseña ni afectar a otras apps conectadas. En el ecosistema de Salesforce, OAuth es el mecanismo oficial para que una integración o una API consuma datos de la plataforma de forma segura.

Es importante no confundirlo: OAuth resuelve la autorización (qué puede hacer una app), no directamente la identidad del usuario. Para verificar quién es la persona se usa OpenID Connect, una capa que se monta sobre OAuth.

OAuth nació para resolver un problema concreto y cotidiano: ¿cómo permito que una aplicación use mis datos de otro servicio sin entregarle mi usuario y contraseña? Antes de su adopción, una app que quería leer tu agenda o publicar en tu nombre te pedía las credenciales directas, lo que era un riesgo de seguridad enorme. OAuth resuelve esto delegando un permiso acotado mediante tokens, no la contraseña.

Cómo funciona el flujo

En un flujo típico de OAuth 2.0 intervienen cuatro actores: el propietario del recurso (el usuario), el cliente (la app que pide acceso), el servidor de autorización (quien emite los tokens) y el servidor de recursos (donde viven los datos). La secuencia más común, el flujo de código de autorización, funciona así:

1. La app redirige al usuario a la pantalla de login del proveedor (por ejemplo, Salesforce o Google).
2. El usuario se autentica y aprueba los permisos que la app solicita, expresados como scopes (alcances).
3. El servidor de autorización devuelve un código de autorización temporal a la app.
4. La app intercambia ese código por un token de acceso (y normalmente un token de refresco), usando su secreto de cliente en una llamada de servidor a servidor.
5. La app presenta el token de acceso al servidor de recursos cada vez que necesita leer o escribir datos.

El token de acceso suele tener vida corta (minutos u horas); cuando vence, el token de refresco permite obtener uno nuevo sin volver a molestar al usuario. Esa separación es clave para la seguridad: si un token de acceso se filtra, su ventana de daño es chica.

Por qué importa para un negocio

Casi toda automatización de procesos que conecta dos sistemas pasa por OAuth. Cuando tu CRM se sincroniza con tu plataforma de facturación, cuando un chatbot consulta el stock en tiempo real, o cuando una herramienta de marketing lee datos de tu base, lo más probable es que la conexión esté autorizada con OAuth. Para el área técnica, significa conexiones auditables y revocables: si un proveedor deja de trabajar con vos, revocás su token y listo, sin tocar contraseñas compartidas ni romper otras integraciones.

OAuth en el contexto de Salesforce

Salesforce usa OAuth 2.0 como mecanismo estándar para sus APIs. Una integración se registra como una Connected App (aplicación conectada) y, según el caso de uso, elige un flujo: el de código de autorización cuando hay un usuario humano aprobando, o el flujo JWT Bearer para integraciones de servidor a servidor que corren sin intervención (ideal para sincronizaciones nocturnas o procesos automáticos). Los permisos quedan acotados por scopes y por los perfiles y conjuntos de permisos del usuario que respalda la conexión.

OAuth no es lo mismo que autenticación

El error más común es tratar OAuth como un sistema de login. OAuth es autorización (delegar permisos), no autenticación (probar identidad). Para saber quién es realmente la persona se usa OpenID Connect, que agrega un token de identidad (ID token) sobre OAuth. Esta distinción aparece todo el tiempo en proyectos de integración:

Errores comunes a evitar

• Confundir autorización con autenticación: usar el token de acceso para "saber quién entró" en vez de OpenID Connect.
• Pedir scopes de más: solicitar permisos amplios cuando alcanzaba con uno acotado aumenta la superficie de riesgo.
• Guardar mal el token de refresco: es una credencial sensible y debe almacenarse cifrada del lado del servidor, nunca en el navegador.
• No prever la revocación: una integración seria contempla qué pasa cuando un token se revoca o expira, sin caerse.

Un ejemplo concreto

Pensá en una empresa de Consumo Masivo en Argentina que conecta su CRM de Salesforce con su sistema de facturación electrónica. En lugar de cargar el usuario y la contraseña de Salesforce dentro del sistema de facturación (una pésima práctica), se crea una Connected App con flujo JWT, con permiso solo para leer pedidos y crear facturas. Si en seis meses cambian de proveedor de facturación, revocan ese token y la conexión se corta de forma limpia, sin afectar a las demás integraciones ni exponer credenciales reutilizables.