Qué es OAuth 2.0?

Guía completa sobre el framework de autorización OAuth 2.0 para delegación de acceso seguro a APIs y autenticación de terceros

OAuth 2.0 es un framework de autorización que permite a aplicaciones obtener acceso limitado a cuentas de usuario en servicios de terceros sin exponer credenciales de usuario. OAuth 2.0 delega autenticación a servidores de autorización e emite access tokens de tiempo limitado, permitiendo delegación segura de acceso a APIs a través de aplicaciones web, móviles y de escritorio.

A diferencia del compartir credenciales directamente, OAuth 2.0 permite a usuarios otorgar permisos específicos (scopes) a aplicaciones sin compartir contraseñas. Una app de edición de fotos puede acceder a Google Photos sin ver tu contraseña de Google. Una herramienta de analytics puede leer datos de repositorio GitHub sin acceso completo a la cuenta. Este modelo de delegación con alcance alimenta integraciones SSO modernas y ecosistemas de APIs de terceros.

OAuth 2.0 funciona junto a protocolos de autenticación como OpenID Connect (OIDC). Mientras OAuth 2.0 maneja autorización (qué puedes hacer), OIDC maneja autenticación (quién eres). La mayoría de implementaciones modernas combinan ambos: OIDC para login, OAuth 2.0 para acceso a APIs.

Last updated: 2026-04-22

Cómo Funciona OAuth 2.0

OAuth 2.0 define cuatro roles: resource owner (usuario), client (aplicación solicitando acceso), authorization server (emite tokens), y resource server (API con datos protegidos). El framework especifica grant types (flujos) para diferentes escenarios, cada uno optimizado para tipos específicos de aplicación y requerimientos de seguridad.

El flujo de autorización inicia cuando una aplicación cliente solicita acceso a recursos protegidos. El authorization server autentica al resource owner, obtiene consentimiento, e emite un access token. El cliente usa este token para acceder a recursos protegidos en el resource server. Los tokens tienen lifetimes y scopes limitados, reduciendo exposición por compromiso de credenciales.

Los access tokens representan decisiones de autorización y contienen scopes (permisos), tiempos de expiración y metadatos. Los refresh tokens habilitan acceso de larga duración sin interacción repetida del usuario. La separación entre access y refresh tokens balancea seguridad (access tokens de corta duración) con experiencia de usuario (renovación transparente de tokens).

Grant Types de OAuth 2.0

Authorization Code Grant

Aplicaciones server-side intercambian códigos de autorización por tokens. Grant más seguro para aplicaciones web con ejecución de código server-side. Authorization code flow soporta PKCE (Proof Key for Code Exchange) para clientes públicos como apps móviles y SPAs.

Client Credentials Grant

Comunicación machine-to-machine sin contexto de usuario. Servicios se autentican con sus propias credenciales y reciben tokens para acceso a APIs. Usado para background jobs, comunicación servicio-a-servicio y flujos de trabajo automatizados.

Implicit Grant (Deprecated)

Originalmente diseñado para aplicaciones basadas en navegador. Deprecated debido a preocupaciones de seguridad (tokens expuestos en URL fragments). Aplicaciones modernas deben usar Authorization Code con PKCE en su lugar.

Resource Owner Password Credentials Grant

Usuario proporciona username/password directamente al cliente. Usar solo para migración legacy o aplicaciones de primera parte confiables. Generalmente desaconsejado debido a riesgo de exposición de credenciales.

Refresh Token Grant

Intercambiar refresh token por nuevo access token sin interacción del usuario. Habilita sesiones de larga duración sin almacenar credenciales de usuario. Los refresh tokens deben almacenarse de forma segura y rotarse regularmente.

Cuándo Usar OAuth 2.0

Usa OAuth 2.0 cuando necesites:

  • Acceso de aplicaciones de terceros a datos de usuario sin compartir credenciales
  • Single sign-on (SSO) entre múltiples aplicaciones
  • Acceso a APIs con alcance con permisos granulares
  • Autenticación móvil y SPA con PKCE
  • Autenticación servicio-a-servicio (Client Credentials)
  • Sesiones de larga duración con refresh tokens
  • Federación con proveedores de identidad (Google, GitHub, Microsoft)

No uses OAuth 2.0 cuando necesites:

  • Autenticación simple de API interna (considera API keys)
  • Solo autenticación de usuario sin autorización (usa OIDC)
  • Acceso único sin sesiones persistentes (tokens stateless como JWT pueden bastar)
  • Sistemas legacy que requieren autenticación con contraseña (considera estrategia de migración)

Señales de que Necesitas OAuth 2.0

  • Aplicaciones de terceros solicitando acceso a datos de tus usuarios
  • Usuarios autenticándose vía social logins (Google, GitHub, LinkedIn)
  • Aplicaciones móviles necesitando acceso seguro a APIs
  • Microservicios requiriendo autenticación servicio-a-servicio
  • Necesidad de revocar acceso de aplicación sin cambiar contraseñas de usuario
  • Requerimientos de compliance para aislamiento de credenciales

Métricas y Medición

Métricas de Seguridad:

  • Tasa de éxito de validación de token: Porcentaje de tokens validando exitosamente (objetivo: >99%)
  • Latencia de revocación de token: Tiempo para que revocación se propague (objetivo: <30 segundos)
  • Intentos de reuso de authorization code: Debe ser cero (indica implementación de PKCE)
  • Tasa de rotación de refresh token: Porcentaje de refresh tokens rotados después de uso

Métricas de Rendimiento:

  • Latencia de endpoint de autorización: Tiempo para completar flujo OAuth (objetivo: <500ms)
  • Latencia de endpoint de token: Tiempo para emitir token (objetivo: <100ms)
  • Latencia de introspección de token: Tiempo para validar token en authorization server (objetivo: <50ms con validación local)

Métricas Operativas:

  • Conteo de tokens activos: Número de access tokens válidos entre aplicaciones
  • Tasa de expiración de token: Porcentaje de requests fallando debido a tokens expirados
  • Tasa de consentimiento: Porcentaje de usuarios otorgando scopes solicitados
  • Tasa de rechazo de scope: Frecuencia de usuarios denegando permisos específicos

Según mejores prácticas de seguridad OAuth 2.0 (RFC 6819), access tokens deben tener lifetimes cortos (minutos a horas) y refresh tokens deben implementar rotación para detectar robo de tokens.

Arquitectura OAuth 2.0

Authorization Server

Emite tokens después de autenticar al resource owner y obtener consentimiento. Implementa endpoints de token para exchange, introspección y revocación. Implementaciones populares incluyen Auth0, Okta, Keycloak y servicios de proveedores cloud (AWS Cognito, Azure AD).

Resource Server

API hosteando recursos protegidos. Valida access tokens antes de otorgar acceso. Realiza validación de scope y aplica permisos. Puede introspectar tokens con authorization server o validar localmente con JWT.

Client Application

Solicita acceso a recursos protegidos. Debe estar registrado con authorization server. Implementa flujos OAuth apropiados para tipo de aplicación. Asegura client credentials y tokens.

Scopes y Permisos

Los scopes definen límites de acceso (read:profile, write:data, admin). Resource servers validan que scopes coincidan con permisos requeridos. Scopes granulares habilitan acceso de least-privilege.

Casos de Uso Reales

Acceso a API de Terceros

  • Integración de social login (Sign in with Google, GitHub)
  • Apps de terceros accediendo datos de usuario (CRM leyendo contactos de email)
  • Marketplaces de APIs con acceso con scope
  • Plataformas de desarrolladores con autorización de API

SSO Empresarial

  • Single sign-on entre aplicaciones organizacionales
  • Federación con proveedores de identidad externos
  • Control de acceso centralizado y auditoría
  • Administración delegada entre departamentos

Aplicaciones Móviles

  • Autenticación segura de API con PKCE
  • Autenticación biométrica integrada con refresh de token
  • Patrones de acceso offline con refresh tokens de larga duración
  • Gestión de sesión entre cambios de dispositivo

Arquitectura de Microservicios

  • Autenticación servicio-a-servicio con Client Credentials
  • Validación y propagación de token en API gateway
  • Claims de autorización delegada entre servicios
  • Arquitectura de red zero-trust con acceso basado en tokens

IoT y Autorización de Dispositivos

  • Device flow para dispositivos con input limitado
  • Acceso a API basado en tokens para dispositivos IoT
  • Permisos con scope para capacidades de dispositivo
  • Autorización de larga duración con refresh tokens

Errores Comunes y Soluciones

Error: Usar implicit grant para aplicaciones de navegador Solución: Usar Authorization Code flow con PKCE. Implicit grant expone tokens en historial del navegador y headers referer. PKCE previene ataques de intercepción de authorization code mientras mantiene compatibilidad con SPA.

Error: Almacenar tokens en localStorage vulnerable a XSS Solución: Almacenar tokens en HttpOnly cookies o almacenamiento seguro del navegador. Para SPAs, usar el patrón Browser Session Management con refresh tokens rotativos. Considerar las implicaciones de seguridad de cada mecanismo de almacenamiento para tu modelo de amenazas.

Error: Access tokens de larga duración sin mecanismo de refresh Solución: Implementar access tokens de corta duración (5-60 minutos) con refresh tokens. Esto limita exposición por robo de token mientras mantiene experiencia de usuario mediante renovación automática de tokens.

Error: No validar scopes en resource server Solución: Resource servers deben validar que scopes del token coincidan con permisos requeridos para cada endpoint. No asumir que aplicación cliente aplica least privilege. Validar tanto firma del token como claims de scope.

Error: Usar Resource Owner Password Credentials grant Solución: Migrar a Authorization Code o Client Credentials grants. Password credentials grant expone contraseñas de usuario a aplicaciones de terceros, derrotando el beneficio de seguridad principal de OAuth 2.0.

Error: No implementar revocación de tokens Solución: Implementar endpoint de revocación para access y refresh tokens. Usuarios deben poder revocar acceso de aplicación inmediatamente. Revocación de token debe propagarse rápidamente entre todos los resource servers.

Preguntas Frecuentes

¿Cuál es la diferencia entre OAuth 2.0 y OpenID Connect (OIDC)? OAuth 2.0 maneja autorización (qué puedes acceder). OIDC agrega capa de autenticación (quién eres) introduciendo ID tokens con claims de identidad de usuario. OIDC usa flujos OAuth 2.0 pero retorna ID tokens junto con access tokens. Usa OIDC cuando necesites autenticación de usuario, OAuth 2.0 cuando necesites delegación de acceso a APIs.

¿Cómo funcionan los refresh tokens? Los refresh tokens son credenciales de larga duración que obtienen nuevos access tokens. Cuando un access token expira, el cliente envía el refresh token al endpoint de token y recibe un nuevo access token. Los refresh tokens deben almacenarse de forma segura, rotarse después de uso y ser revocables. No todos los grant types soportan refresh tokens.

¿Qué es PKCE y cuándo debo usarlo? PKCE (Proof Key for Code Exchange) previene ataques de intercepción de authorization code en clientes públicos. Usa PKCE para todas las aplicaciones basadas en navegador (SPAs), apps móviles y cualquier cliente que no pueda almacenar de forma segura un client secret. PKCE vincula el authorization code a un code verifier conocido solo por el cliente.

¿Debo usar JWT o tokens opacos para access tokens? Los JWTs habilitan validación local sin round-trips al authorization server, mejorando rendimiento y reduciendo carga del servidor. Tokens opacos requieren introspección pero son más simples de revocar. Usa JWTs cuando resource servers necesiten validación rápida, tokens opacos cuando latencia de revocación sea crítica. Muchas implementaciones usan JWT access tokens con refresh tokens opacos.

¿Cómo aseguro client credentials en clientes públicos? Clientes públicos (SPAs, apps móviles) no pueden almacenar de forma segura client secrets. Usar PKCE para proteger authorization codes. Considerar dynamic client registration o client authentication basada en assertions. Para SPAs, evitar client secrets completamente—usa token mediation mediante un componente backend si requiere seguridad adicional.

¿Qué scopes debo definir? Define scopes basándose en límites de acceso relevantes para tu dominio: tipos de recursos (read:profile, write:documents), capacidades funcionales (admin, analytics) o grupos de APIs (calendar, email). Evita scopes excesivamente granulares (causa fatigue de permisos) o excesivamente amplios (viola least privilege). Prueba UX de scopes con pantallas reales de consentimiento.

¿Cómo implemento revocación de tokens? Implementar endpoint de revocación según RFC 7009. Cuando usuarios revocan acceso de aplicación, invalidar refresh token y todos los access tokens asociados. Para JWT access tokens, mantener blacklist de tokens o usar tiempos de expiración cortos con refresh tokens revocables. Considera caching de introspección de tokens para tokens accedidos frecuentemente.

Cómo Aplica en la Práctica

OAuth 2.0 es la base para autorización moderna de APIs e integración de terceros. La mayoría de desarrolladores encuentran OAuth 2.0 mediante botones de social login, integraciones de APIs o implementaciones SSO empresariales. Entender grant types, consideraciones de seguridad y gestión de tokens permite arquitectura de aplicación segura.

Estrategia de Implementación:

  • Elegir grant type apropiado para arquitectura de aplicación
  • Registrar aplicaciones cliente con authorization server
  • Implementar flujos OAuth con PKCE para clientes públicos
  • Validar tokens y scopes en resource servers
  • Manejar refresh y expiración de tokens apropiadamente
  • Implementar almacenamiento seguro de tokens para tipo de cliente

Mejores Prácticas de Seguridad:

  • Usar access tokens de corta duración con rotación de refresh token
  • Validar redirect URIs estrictamente para prevenir ataques de open redirect
  • Implementar PKCE para todos los clientes públicos
  • Almacenar tokens de forma segura basándose en tipo de cliente
  • Validar scopes en cada request de resource server
  • Implementar revocación de tokens y gestión de consentimiento

Decisiones de Arquitectura:

  • Usar Authorization Code con PKCE para SPAs y apps móviles
  • Usar Client Credentials para comunicación servicio-a-servicio
  • Considerar JWT access tokens para validación distribuida
  • Centralizar introspección de tokens para aplicaciones sensibles a revocación
  • Implementar authorization server o usar servicio gestionado (Auth0, Okta)
  • Diseñar scopes para least privilege y comprensión de usuario

OAuth 2.0 en Azion

Azion Functions permite integración OAuth 2.0 en la capa de la plataforma web:

  • Validación de tokens en Functions antes de reenviar requests a servidores origin
  • Integración de authorization server con introspección de tokens en edge
  • Extracción de scope para decisiones de autorización granulares
  • Rate limiting y prevención de abuso para endpoints de tokens
  • Real-Time Metrics para eventos de autenticación y uso de tokens

La naturaleza distribuida de la red global de Azion permite validación de tokens más cerca de usuarios, reduciendo latencia para verificaciones de autorización mientras mantiene seguridad. Functions puede cachear resultados de introspección de tokens para rendimiento mejorado sin comprometer capacidades de revocación de tokens.

Aprende más sobre Functions y API Security.

Sources

Contenido Relacionado

Comunidad