OAuth

Conceptos Clave

  • tipo de SSO Single Sign-On
  • autorizacion (no autenticación)
  • estándar basado en JSON
  • acceso delegado mediante tokens
  • flujo seguro sin compartir credenciales (UN, PW – redes sociales)
  • usado en api modernas, apps móviles, SPAs y servicios distribuidos

Componentes Principales

  • Resource Owner (RO)
    • Usuario que concede acceso a un recurso protegido.
  • Client (Aplicación Cliente)
    • App que solicita acceso delegado a recursos del usuario.
  • Authorization Server (AS)
    • Emite tokens y gestiona permisos y consentimientos.
  • Resource Server (RS)
    • Servicio que protege los datos y valida tokens.
  • Tokens
    • Access Token: acceso a recursos protegidos.
    • Refresh Token: permite renovar el access token sin reautenticar.

Flujos (Grant Types)

  • Authorization Code
    • El más seguro. Ideal para apps web con backend.
  • PKCE (Proof Key for Code Exchange)
    • Variante moderna segura para SPAs y apps móviles.
  • Client Credentials
    • Comunicación servicio-a-servicio sin usuario.
  • Device Code
    • Autenticación en dispositivos limitados (TVs, IoT).
  • Implicit (obsoleto)
    • Ya no recomendado por vulnerabilidades.

Riesgos y Buenas Prácticas

  • evitar tokens largos en URL
  • usar HTTPS siempre
  • validar el redirect_uri
  • usar PKCE cuando sea posible
  • establecer expiraciones cortas
  • rotación de tokens
  • evitar scopes excesivamente amplios

Enlaces y Recursos

OpenID Connect (OIDC)

  • protocolos
  • OAuth
  • auntenticacion
  • capa superior de OAuth enfocada en autenticación
  • OAuth = autorización
    OIDC = autenticación
  • añade ID Token (JWT) que identifica al usuario
  • Relying Party (RP): aplicación que confía en el Identity Provider
  • interoperable, RESTful y ampliamente usado
  • fundamental en SSO moderno
  • útil para apps web, móviles y APIs distribuidas

Recursos OIDC

Tabla Comparativa SSO vs OAuth

SSO OAuth  
SSO OAuth  
Cómo funciona El usuario se autentica una vez con un IdP El usuario autoriza a una app a acceder a sus datos en otra app
Cuándo usar Para simplificar el proceso de inicio de sesión Para otorgar acceso delegado a datos
Ejemplos Salesforce (una sola sesión) Apps que publican en redes sociales en nombre del usuario

OAuth — Conceptos Avanzados y Profundización

Arquitectura y Modelo de Confianza

  • OAuth como Framework
    • No define un único método; proporciona un conjunto adaptable de mecanismos.
  • Modelo de Confianza entre Roles
    • Cliente confía en el Authorization Server para gestionar permisos del usuario.
    • Resource Server confía en el AS para validar tokens.
    • Ningún actor necesita las credenciales del otro → principio “Zero Knowledge”.
  • Desacoplamiento
    • El AS y el RS pueden ser servicios distintos → microservicios, escalabilidad, delegación.

Scopes en Profundidad

  • Scopes granulares
    • Permiten diseñar permisos finos: lectura, escritura, operaciones específicas.
  • Scopes compuestos o jerárquicos
    • Muchos proveedores implementan scopes internos anidados.
  • Scope Inflation Risk
    • El cliente pide más permisos de los necesarios.
    • Contramedida: consent guided by minimal access.
  • Scopes dinámicos
    • Algunos proveedores permiten construir scopes en tiempo de ejecución.

Tokens: Detalles Técnicos Avanzados

  • Formato del Access Token
    • Opaque vs JWT
    • Opaque es más seguro para evitar exfiltración de datos.
  • Token Introspection
    • Proceso para validar tokens no-JWT mediante un endpoint seguro.
  • Token Binding
    • Vincula el token al dispositivo/cliente para evitar replay attacks.
  • JWT Claims Avanzados
    • aud: define quién debe aceptar el token.
    • jti: identifica un token de forma única → revocación.
    • nonce: mitigación de ataques de reproducción en flujos híbridos.

Seguridad Avanzada en OAuth

  • Ataques Comunes
    • Authorization Code Interception
    • Token Leakage
    • Redirect Manipulation
    • Confused Deputy Problem
  • Medidas Avanzadas
    • PKCE obligatorio incluso para apps con backend.
    • State parameter para evitar CSRF.
    • Nonce en OIDC para mitigar reproducción.
    • Validación del issuer y audience del token.
    • Caducidad ultracorta para Access Tokens; refresh rotativos.

Patrones de Implementación

  • Backend for Frontend (BFF) + OAuth
    • Patrones seguros para SPAs evitando exponer tokens en el navegador.
  • Token Exchange (RFC 8693)
    • Permite intercambiar un tipo de token por otro
    • Usado en arquitecturas complejas con microservicios.
  • OAuth para M2M
    • Uso de Client Credentials + scopes mínimos + rotación frecuente.

OAuth en Entornos Empresariales

  • Gobernanza y Cumplimiento
    • Control de consentimientos del usuario
    • Auditoría de emisiones e invalidaciones de tokens
    • Segmentación por entorno (DEV, QA, PROD)
  • Integración con IAM corporativo
    • Compatibilidad con LDAP, Active Directory, proveedores de identidad federada.
  • Multi-Tenant OAuth
    • Distinción entre “tenant-aware” y “tenant-isolated” tokens.
    • Aislamiento organizacional mediante claims específicos.

Extensiones Relevantes del Estándar (sin repetir OIDC)

  • OAuth 2.1 (draft)
    • Eliminación del flujo Implicit
    • PKCE como obligatorio
    • Endpoints simplificados
  • OAuth 2.0 Device Authorization Grant (RFC 8628)
    • Autenticación en dispositivos con UI limitada.
  • JAR / JARM
    • JWT Secured Authorization Request
    • JWT Secured Authorization Response
    • Proporcionan integridad y no repudio en solicitudes/respuestas.
  • PAR — Pushed Authorization Requests
    • El cliente envía la solicitud de autorización directamente al AS, evitando manipulación en el navegador.

Diseño Seguro de APIs con OAuth

  • API Gateway + OAuth
    • Centraliza autenticación, validación de tokens y throttling.
  • Resource Indicators
    • Permiten solicitar tokens específicos para distintos recursos/servicios.
  • Políticas de Autorización Basadas en Claims
    • Decisiones dinámicas según atributos del token (rol, grupo, device_id).
  • Service Mesh + OAuth
    • Token exchange interno + mTLS + autorización granular per-servicio.

OAuth en Microservicios y Arquitecturas Zero Trust

  • Zero Trust
    • Autorización continua mediante tokens de vida corta.
    • Validación estricta por servicio, no confiar en la red interna.
  • Workload Identity
    • Servicios que actúan como clientes: tokens emitidos para workloads, no usuarios.
  • Separación de dominios
    • Cada microservicio puede requerir un scope distinto → control de privilegios.

Testing y Validación

  • Pruebas Automáticas
    • Validación de flujos OAuth en pipelines CI/CD.
    • Mock de Authorization Server para pruebas unitarias.
  • Herramientas
    • OAuth2 Proxy
    • Curity OAuth Tools
    • MITREid Test tools