Tema 14
Los ecosistemas modernos de identidad no funcionan solo con ideas abstractas de SSO o federación. Necesitan protocolos concretos que definan cómo se piden permisos, cómo se transporta identidad, cómo se validan tokens y cómo se establece confianza entre aplicaciones. OAuth 2.0, OpenID Connect y SAML cumplen ese papel, pero resuelven problemas distintos y suelen confundirse con frecuencia.
En identidad y acceso, muchas confusiones nacen de usar nombres de protocolos como si fueran sinónimos de “login moderno”. En realidad, cada uno tiene un propósito distinto. OAuth 2.0 no fue creado originalmente para autenticar usuarios. OpenID Connect agrega identidad sobre OAuth. SAML viene de una tradición distinta, muy asociada a federación y SSO empresarial.
Comprender estas diferencias evita errores de diseño como usar OAuth para algo que requiere autenticación explícita, o adoptar SAML en escenarios donde APIs y aplicaciones móviles se benefician más de enfoques basados en tokens modernos.
Este tema se centra en el mapa conceptual y arquitectónico. Más adelante veremos APIs y tokens con más detalle, pero aquí importa entender quién participa, qué se intercambia y qué problema resuelve cada protocolo.
En este ámbito, un protocolo define reglas para que sistemas distintos puedan interoperar en procesos de autenticación, federación o autorización delegada. Establece mensajes, roles, validaciones y formatos que permiten compartir confianza de forma verificable.
Sin protocolos estandarizados, cada integración requeriría acuerdos ad hoc difíciles de mantener, auditar y asegurar. Por eso estos protocolos existen: no para agregar complejidad por sí misma, sino para hacer interoperable un problema que naturalmente involucra múltiples actores.
OAuth 2.0 es un framework de autorización delegada. Su propósito principal es permitir que una aplicación obtenga acceso limitado a recursos protegidos en nombre de un usuario o de una entidad, sin necesidad de conocer la contraseña del usuario.
La idea original no es “hacer login”, sino delegar acceso. Por ejemplo, permitir que una aplicación acceda a cierta información de una cuenta bajo consentimiento y alcance definido.
Esto es importante porque mucha gente dice “autenticación con OAuth” como si el protocolo por sí mismo resolviera identidad. En sentido estricto, OAuth 2.0 trata de autorización, no de autenticación del usuario final como objetivo primario.
En OAuth 2.0 suelen aparecer estos roles:
Esta separación permite que una aplicación cliente acceda a recursos sin recibir directamente las credenciales del usuario para el sistema destino.
OAuth 2.0 resuelve sobre todo delegación de acceso. Algunos escenarios típicos son:
En todos estos casos, la pregunta principal es “¿puede esta aplicación acceder a este recurso con este alcance?”, no necesariamente “¿quién es exactamente el usuario?” en términos de identidad federada completa.
Aunque muchas implementaciones usan OAuth 2.0 como parte de un flujo de login, el protocolo por sí solo no estandariza completamente cómo una aplicación obtiene información de identidad del usuario autenticado. Puede existir un token válido para acceso a recursos sin que eso implique una semántica uniforme de identidad para el cliente.
Por eso aparece OpenID Connect, que se apoya en OAuth 2.0 y agrega una capa explícita para autenticación e identidad.
OpenID Connect, u OIDC, es una capa de identidad construida sobre OAuth 2.0. Su función es permitir que una aplicación confirme la identidad del usuario autenticado y obtenga información estandarizada sobre él.
En otras palabras:
Esto convierte a OIDC en una opción muy frecuente para login moderno en aplicaciones web, móviles y ecosistemas API-friendly.
OIDC agrega elementos clave que OAuth no definía con el mismo foco:
Esto hace que una aplicación pueda decir con mayor claridad no solo “tengo autorización para acceder a algo”, sino también “sé quién es el usuario según un proveedor confiable”.
OIDC suele encajar bien cuando el ecosistema ya trabaja con tokens, APIs y arquitecturas distribuidas. Por eso se volvió dominante en muchos entornos modernos.
SAML, o Security Assertion Markup Language, es un estándar de federación más antiguo que todavía sigue muy presente en entornos empresariales. Está especialmente asociado a SSO entre aplicaciones corporativas y a relaciones entre un proveedor de identidad y un service provider.
Su enfoque gira en torno a afirmaciones de identidad y confianza entre dominios, con un estilo más típico de aplicaciones web empresariales tradicionales.
Aunque hoy muchas arquitecturas nuevas prefieren OIDC para ciertos escenarios, SAML sigue siendo muy común en integraciones empresariales y SaaS corporativo.
Una forma práctica de verlo es la siguiente:
No se trata de declarar uno “mejor” en abstracto. Se trata de ver qué encaja mejor con el entorno, las integraciones existentes, la experiencia esperada y los sistemas involucrados.
| Protocolo | Problema principal que resuelve | Uso típico |
|---|---|---|
| OAuth 2.0 | Autorización delegada | Acceso a APIs y recursos protegidos |
| OpenID Connect | Autenticación e identidad sobre OAuth | Login moderno, SSO, aplicaciones web y móviles |
| SAML | Federación de identidad y SSO empresarial | Aplicaciones corporativas y SaaS tradicionales |
Una frase muy común en la práctica es “hacemos login con OAuth”. En muchos contextos se entiende qué quiere decir, pero técnicamente es imprecisa. Si lo que realmente se busca es autenticar usuarios y recibir identidad estandarizada, el protagonista suele ser OIDC sobre OAuth 2.0, no OAuth “solo”.
Esta distinción importa porque evita arquitecturas ambiguas y decisiones inseguras basadas en supuestos erróneos sobre tokens y semántica de identidad.
Estos protocolos trabajan con artefactos que representan autorización o identidad. Dependiendo del protocolo y del flujo, pueden aparecer:
Lo importante no es solo recibir uno de estos artefactos, sino validarlo correctamente: emisor, audiencia, vigencia, firma y condiciones contextuales.
La elección del protocolo también impacta experiencia y arquitectura. SAML suele aparecer en flujos más centrados en navegador y portales empresariales. OIDC suele sentirse más natural en aplicaciones modernas con SPAs, móviles y backends que consumen APIs. OAuth 2.0 aparece de forma transversal cada vez que el problema principal es acceso delegado a recursos.
Esto no significa que cada protocolo esté completamente encerrado en un solo estilo, pero sí que existen afinidades prácticas claras.
No hay una regla única, pero algunas orientaciones son útiles:
La elección real también depende de capacidades del proveedor de identidad, ecosistema existente, requisitos regulatorios y perfil de las aplicaciones integradas.
OAuth 2.0, OpenID Connect y SAML son piezas centrales del ecosistema moderno de identidad, pero cada una cumple un papel diferente. Entender bien esa diferencia evita errores de arquitectura y permite diseñar integraciones más claras, seguras y sostenibles. Lo importante no es memorizar siglas, sino saber qué problema se está resolviendo realmente.
En el próximo tema nos enfocaremos en autenticación y autorización en APIs: scopes, claims, JWT e introspección, donde estos conceptos se vuelven especialmente concretos.