Definición rápida
OAuth (Open Authorization) es un estándar de autorización abierto que permite a una aplicación acceder a recursos de otra en nombre de un usuario, sin que el usuario tenga que compartir sus credenciales (usuario y contraseña) con la primera aplicación.
¿Qué es OAuth?
OAuth resuelve un problema fundamental de seguridad en las integraciones digitales. Antes de OAuth, si querías que una aplicación accediera a tus datos de Google (ej: contactos), tenías que darle tu usuario y contraseña de Google a esa aplicación. Eso es enormemente peligroso —si la app es maliciosa o tiene un breach, tus credenciales quedan expuestas.
OAuth introduce un intermediario: en lugar de compartir credenciales, el usuario autoriza a la aplicación a acceder a recursos específicos. Google (o Facebook, o GitHub) actúa como el «guardián» y emite un «token de acceso» —un permiso temporal y revocable que la aplicación puede usar para acceder solo a lo que el usuario autorizó.
Es el estándar detrás de los botones «Iniciar sesión con Google», «Continuar con Facebook» y «Log in with GitHub» que ves en miles de aplicaciones. OAuth 2.0 (la versión actual) fue publicado en 2012 y es mantenido por el IETF.
¿Cómo funciona OAuth en la práctica?
El flujo OAuth más común (Authorization Code Flow) tiene estos pasos:
- El usuario hace clic en «Iniciar sesión con Google» en tu aplicación.
- Redirección al Authorization Server: Tu app redirige al usuario a Google, especificando qué permisos (scopes) necesitas: «Queremos acceder a tu perfil básico y email».
- El usuario autoriza: Google muestra al usuario exactamente qué permisos está concediendo y el usuario acepta (o rechaza).
- Authorization Code: Google redirige al usuario de vuelta a tu app con un código temporal de un solo uso.
- Intercambio por Access Token: Tu servidor intercambia ese código con Google por un Access Token (usando tu client_secret). Este intercambio ocurre server-to-server, nunca expuesto al navegador.
- Acceso a recursos: Tu app usa el Access Token para hacer requests a la API de Google en nombre del usuario.
OAuth se complementa con Single Sign-On (SSO) y con OpenID Connect (OIDC), que extiende OAuth para proveer también información de identidad del usuario.
Ejemplos reales en LATAM
Startups usando «Login con Google»: Prácticamente todas las startups SaaS de LATAM ofrecen «Iniciar sesión con Google» o «Iniciar sesión con GitHub» como método de autenticación. Reduce la fricción del registro y aumenta la seguridad (Google/GitHub manejan la autenticación).
Integraciones de datos: Una startup de analytics en Colombia necesita acceder a los datos de Google Analytics de sus clientes. Con OAuth, el cliente autoriza el acceso sin compartir su contraseña de Google.
Plataformas de automatización: n8n usa OAuth para conectarse a servicios como Google Sheets, Slack, Notion o GitHub en nombre del usuario, sin almacenar sus contraseñas.
OAuth vs OpenID Connect vs SAML
| Protocolo | Propósito | Uso típico |
|---|---|---|
| OAuth 2.0 | Autorización (acceso a recursos) | APIs, integraciones |
| OpenID Connect | Autenticación (quién eres) | «Login con Google» |
| SAML 2.0 | Autenticación enterprise | SSO corporativo |
Errores comunes con OAuth
- Pedir demasiados scopes: Solicitar acceso a todos los datos disponibles cuando solo necesitas el email es una mala práctica de seguridad y privacidad. Pide el mínimo necesario.
- Exponer el client_secret: El client_secret nunca debe estar en código frontend o en la URL. Solo en el backend seguro.
- Ignorar la renovación de tokens: Los Access Tokens expiran (típicamente en 1 hora). Implementa correctamente el flujo de Refresh Token para renovar el acceso sin requerir que el usuario vuelva a autorizarse.
- No manejar la revocación: Los usuarios pueden revocar el acceso desde los settings de Google/Facebook. Tu app debe manejar el error de token inválido gracefully.
Preguntas Frecuentes (FAQ)
¿OAuth 2.0 y OAuth 1.0 son compatibles?
No. Son protocolos distintos. OAuth 1.0 requería firmar cada request criptográficamente. OAuth 2.0 simplificó esto usando HTTPS y tokens Bearer. Casi todos los servicios modernos usan OAuth 2.0; OAuth 1.0 está prácticamente obsoleto (Twitter fue uno de los últimos en usarlo).
¿Debo implementar OAuth desde cero?
Casi nunca. Usa librerías y servicios de identidad: Auth0, Supabase Auth, Clerk, NextAuth.js, o las librerías oficiales del proveedor (google-auth-library, passport.js). Implementar OAuth desde cero es complejo y propenso a errores de seguridad.
¿OAuth es lo mismo que autenticación?
No exactamente. OAuth es principalmente un protocolo de autorización (qué puede hacer una app). La autenticación (quién eres) se añade con OpenID Connect encima de OAuth. Cuando haces «Login con Google», estás usando OpenID Connect + OAuth juntos.
