¿Qué son las credenciales OAuth 2.0?
OAuth 2.0 es el estándar de autorización más usado en APIs modernas. Las credenciales OAuth incluyen cuatro tipos de tokens: Client ID (identificador público de tu aplicación), Client Secret (clave privada que nunca exponés al cliente), Access Token (token temporal con permisos específicos, típicamente JWT) y Refresh Token (token de larga duración para renovar access tokens expirados).
Cada credencial cumple un rol específico: el Client ID identifica tu app ante el servidor OAuth, el Client Secret autentica que realmente sos vos (nunca lo incluyas en código frontend), el Access Token autoriza cada request (se envía en el header Authorization: Bearer) y el Refresh Token te permite obtener nuevos access tokens sin pedir login al usuario. Los access tokens suelen durar minutos u horas; los refresh tokens pueden durar días o meses.
Este generador produce credenciales con formato realista: Client IDs de 32-64 caracteres alfanuméricos o UUIDs, Client Secrets con prefijos tipo sk_live_ o cs_prod_, Access Tokens en formato JWT (tres partes separadas por puntos) o strings largos aleatorios, y Refresh Tokens de 64-128 caracteres. Útil para mockear responses, documentar APIs, crear fixtures de test o diseñar interfaces.
Errores comunes al implementar OAuth
El error número uno es exponer el Client Secret en el frontend. El secret debe vivir solo en tu backend; si lo incluís en JavaScript del navegador, cualquiera puede leerlo y suplantar tu app. Usá el flujo PKCE (Proof Key for Code Exchange) para apps públicas como SPAs o mobile.
Otro problema frecuente: no validar el scope del token. Un access token con scope read:user no debería poder escribir datos. Verificá siempre que los permisos del token coincidan con la operación. También es clave no asumir que el token es eterno: implementá lógica para detectar tokens expirados (status 401) y renovarlos automáticamente con el refresh token.
Muchos devs olvidan rotar los refresh tokens. Cuando generás un nuevo access token, emití también un nuevo refresh token y revocá el anterior (rotation pattern). Esto limita el daño si un refresh token se filtra. Y nunca guardes tokens en localStorage sin encriptar: preferí cookies HttpOnly o almacenamiento seguro nativo en mobile.
Por último, no loguees tokens completos. Si necesitás debuggear, registrá solo los últimos 6 caracteres (token ending in ...a1b2c3). Un token en un log puede comprometer toda tu seguridad si esos logs son accesibles o se filtran.
Diferencias entre flujos OAuth 2.0
OAuth 2.0 define varios flujos según tu tipo de aplicación. Authorization Code es el más seguro para apps con backend: el usuario autoriza, recibís un código temporal, lo intercambiás por tokens en el servidor (donde guardás el secret). Este flujo previene que tokens aparezcan en URLs del navegador.
Authorization Code + PKCE extiende el flujo anterior para apps públicas (SPAs, mobile): generás un code_verifier random, enviás su hash (code_challenge) al pedir autorización y después probás que conocías el verifier original. Esto hace innecesario el Client Secret, ideal cuando no tenés backend o no podés proteger secrets.
Client Credentials es para comunicación servidor-a-servidor (machine-to-machine): tu backend autentica directamente con Client ID + Secret, sin intervención de usuario. Útil para jobs, microservicios o integraciones backend. Los tokens suelen tener scope limitado a recursos propios de la app.
Implicit (deprecated) entregaba tokens directo en la URL de redirección, sin código intermedio. Era práctico pero inseguro: tokens expuestos en historial del navegador. Reemplazalo por Authorization Code + PKCE. Resource Owner Password (también deprecated) implicaba enviar usuario/contraseña a tu app; solo válido en escenarios legacy donde controlás ambos extremos.
Buenas prácticas de seguridad OAuth
Siempre usá HTTPS en producción: OAuth sin TLS es como enviar contraseñas en texto plano. Validá el redirect_uri exacto (sin wildcards) para prevenir ataques de open redirect. Guardá una whitelist de URIs permitidas y rechazá cualquier variación.
Implementá state parameter para prevenir CSRF: generá un token random antes de redirigir al servidor OAuth, guardalo en sesión y verificá que coincida al volver. Si difiere, abortá el flujo. Algunos proveedores también soportan nonce para prevenir replay attacks en tokens JWT.
Rotá secrets periódicamente (cada 90-180 días) y revocá tokens cuando el usuario hace logout o cambia contraseña. Muchas APIs OAuth ofrecen endpoints de revocación; usarlos invalida tokens inmediatamente. No confíes solo en la expiración: un refresh token robado puede seguir funcionando meses.
Limitá el scope al mínimo necesario: si solo leés perfil, no pidas write. Esto reduce el impacto de una brecha. Y monitoreá uso anómalo: muchos access tokens desde IPs distintas en minutos puede indicar filtración. Implementá rate limiting por token para mitigar abuso.