¿Qué es OAuth 2.0 y cómo conecta aplicaciones sin compartir contraseñas?
Publicado el 2026-10-20 por frfrand
OAuth 2.0 explicado con un ejemplo de permisos delegados, scopes, redirecciones y diferencias entre autorización e identidad.
OAuth 2.0 es un marco para conceder acceso limitado a una aplicación sin entregarle directamente las credenciales de tu cuenta en otro servicio. Por eso aparece cuando querés vincular un calendario, almacenamiento o sistema externo con una herramienta que utilizás.
No es simplemente un botón de «iniciar sesión con Google». También existen flujos de OAuth utilizados para autorizar acceso a APIs.
El ejemplo de un valet
Imaginá que dejás tu coche en un estacionamiento. En lugar de darle todas las llaves de tu casa al personal, entregás una llave que sirve para una función concreta.
OAuth busca un objetivo similar: autorizar operaciones específicas durante cierto alcance y condiciones, sin compartir la contraseña principal con la aplicación que solicita acceso.
La comparación es imperfecta, porque los tokens pueden copiarse si se filtran y cada proveedor establece sus propias reglas.
¿Cómo suele funcionar?
Una aplicación quiere consultar tu calendario. Te redirige al servicio que administra la cuenta. Allí iniciás sesión si hace falta y revisás qué acceso se está solicitando.
Si lo autorizás, la aplicación puede recibir un código de autorización y canjearlo de forma segura por credenciales de acceso según el flujo implementado. El token obtenido permite llamar a una API dentro de los permisos concedidos.
En el flujo moderno de código de autorización se utiliza habitualmente PKCE, que agrega una protección importante, en especial para clientes públicos.
¿Qué es un scope?
Un scope indica un alcance de autorización definido por el servicio. Por ejemplo, una integración puede solicitar leer eventos de calendario en lugar de pedir acceso a todos los recursos.
Pedir menos permisos es una buena práctica. No tiene sentido solicitar capacidad de borrar archivos cuando la integración únicamente necesita listar nombres.
Pero los scopes no reemplazan todas las comprobaciones de seguridad de la API. Cada proveedor debe validar además qué recursos reales puede consultar el titular.
OAuth no es lo mismo que OpenID Connect
Aquí aparece una confusión común. OAuth se centra en autorización delegada. OpenID Connect utiliza OAuth 2.0 como base y añade una capa de identidad para que una aplicación pueda autenticar al usuario.
Por eso no conviene tomar un token de acceso de cualquier servicio y usarlo como si demostrara por sí mismo la identidad de una persona ante tu aplicación.
¿Qué riesgos existen?
Una URL de redirección mal validada puede permitir enviar códigos a un destino indebido. Un token robado puede ser utilizado dentro de su alcance mientras siga válido. Pedir permisos excesivos aumenta el impacto de un compromiso.
Las implementaciones modernas necesitan proteger state cuando corresponde, utilizar PKCE en los flujos adecuados, validar redirecciones y almacenar tokens de forma segura. No basta con copiar una URL de un tutorial.
¿Y el refresh token?
Algunos proveedores entregan credenciales que permiten obtener nuevos tokens de acceso sin repetir toda la interacción. No todos los flujos las utilizan ni tienen las mismas políticas.
Deben protegerse especialmente: si alguien obtiene un refresh token válido, puede prolongar el acceso según las reglas del proveedor. Conviene comprobar revocación, rotación y expiración.
Un caso de uso real
Imaginá un asistente que ayuda a organizar reuniones y necesita consultar tu disponibilidad. Con un flujo correcto de OAuth, podés autorizar acceso a tu calendario sin darle al asistente tu contraseña principal.
Si después dejás de utilizar esa aplicación, deberías poder revocar el acceso desde la cuenta del proveedor cuando lo admita.
¿Qué relación tiene con ArduMaker?
Al conectar cuentas externas o integrar una herramienta con servicios gestionados desde ArduMaker, OAuth puede ser una opción cuando el proveedor lo soporta. El objetivo debe ser conceder solo las capacidades necesarias, con autorización explícita y revocable.
En una frase: OAuth permite delegar acceso acotado. No elimina la necesidad de proteger tokens ni sustituye una política de permisos bien diseñada.
Fuentes: RFC 6749, OAuth 2.0 · RFC 7636, PKCE · OpenID Connect.