OAuth

Definición

OAuth (de Open Authorization) es un protocolo abierto que permite a una aplicación obtener acceso limitado a los datos de un usuario en otro servicio sin que el usuario tenga que compartir su contraseña. Es el estándar de facto detrás del clásico botón "Iniciar sesión con Google" o "Conectar con GitHub".

La versión vigente, OAuth 2.0 (RFC 6749), publicada en 2012, es la que se usa hoy prácticamente en todas partes. La versión 1.0 quedó obsoleta por su complejidad criptográfica.

Conviene tener clara una distinción que confunde a casi todo el mundo: OAuth es autorización, no autenticación. OAuth dice "esta app puede leer tus contactos de Google". Para verificar quién eres (autenticación) se usa OpenID Connect (OIDC), que se monta encima de OAuth añadiendo un ID token.

Cómo funciona

El flujo más común y seguro, llamado Authorization Code Flow, tiene cinco pasos:

1. Redirección: la app del cliente (por ejemplo, una herramienta de gestión de proyectos) redirige al usuario al servidor de autorización (Google) con parámetros como client_id, redirect_uri, scope (qué permisos pide) y state (anti-CSRF).
2. Consentimiento: Google muestra una pantalla tipo "La app Tareas Pro quiere acceder a tu calendario y tus contactos. ¿Aceptas?". El usuario aprueba.
3. Código de autorización: Google redirige de vuelta al redirect_uri con un código de un solo uso (?code=ABC123).
4. Intercambio: el backend de la app cambia ese código por un access token (y opcionalmente un refresh token) llamando a POST /token con su client_secret.
5. Acceso a recursos: la app usa el access token en el header Authorization: Bearer xyz... para llamar a las APIs de Google.

El access token suele caducar en 1 hora; el refresh token sirve para obtener nuevos access tokens sin pedir consentimiento otra vez, y puede durar semanas o meses.

Ejemplo práctico

En AE Works construimos un dashboard que muestra a un cliente sus pedidos en IMDICA junto con sus métricas de Google Analytics. Para acceder a esos datos sin pedir al usuario la contraseña de Google:

1. Registramos la app en Google Cloud Console y obtenemos client_id y client_secret.
2. Definimos los scopes: https://www.googleapis.com/auth/analytics.readonly.
3. El usuario hace clic en "Conectar Analytics" → flujo Authorization Code.
4. Google nos devuelve un token con permiso solo para leer Analytics. No podemos tocar su Gmail, Drive, ni nada más.
5. Guardamos el refresh token cifrado en nuestra base de datos y consultamos GA4 cuando hace falta.

Si el cliente cancela el permiso desde su cuenta Google, nuestros tokens dejan de funcionar al instante. Esa es la gracia: el usuario tiene el control, no la app.

Tipos de flujo (grants)

OAuth 2.0 define varios grant types, cada uno para un escenario:

• Authorization Code + PKCE: estándar moderno para apps web y móviles. PKCE protege contra interceptación del código.
• Client Credentials: cuando una máquina llama a otra sin usuario implicado (cron, integraciones backend).
• Refresh Token: para renovar access tokens sin nueva interacción.
• Device Code: para dispositivos sin teclado/navegador (TVs, IoT). Te dan un código corto que metes desde el móvil.
• Implicit Flow (obsoleto): se usaba en SPAs, hoy desaconsejado.
• Resource Owner Password Credentials (obsoleto): el usuario daba la contraseña a la app. Solo para migraciones legacy.

Errores comunes

• Confundir OAuth con autenticación: si necesitas saber quién es el usuario, usa OpenID Connect además de OAuth.
• Guardar tokens en localStorage: vulnerable a XSS. Usa cookies httpOnly + Secure + SameSite.
• No validar el state: sin él, un atacante puede engañar al usuario para vincular su cuenta a la sesión del atacante (CSRF).
• Pedir scopes excesivos: si pides acceso al Drive completo cuando solo necesitas leer un archivo, los usuarios desconfían y abandonan.
• No rotar client_secret si se filtra: tratarlo como una contraseña de servidor.

Cuándo usarlo

Sí, usa OAuth cuando:

• Necesitas acceder a datos de un usuario en un servicio de terceros.
• Quieres ofrecer "Login con Google/Microsoft/GitHub" para reducir fricción.
• Estás construyendo una plataforma que otras apps van a integrar.

No, evítalo cuando:

• Solo necesitas autenticar usuarios dentro de tu propio sistema cerrado (un email + password o passkeys es más simple).
• Estás haciendo comunicación máquina-a-máquina interna sin usuario (basta una API key bien gestionada).

Referencias

• RFC 6749 · The OAuth 2.0 Authorization Framework — especificación oficial
• OAuth.net — guía mantenida por la comunidad con flujos visuales
• Auth0 · Authorization Code Flow — explicación práctica con diagramas