OAuth explicado: roles, flujo PKCE y OAuth vs SAML
OAuth explicado
¿Qué es OAuth? Roles, flujo PKCE, OAuth vs SAML vs OIDC | We.Inc
OAuth 2.0 en palabras sencillas: los cuatro roles, el flujo authorization code con PKCE paso a paso, los scopes y en qué se diferencia OAuth de OpenID Connect y SAML.
OAuth 2.0 es un estándar que permite que una app actúe en tu nombre en otro servicio sin ver nunca tu contraseña. Apruebas una solicitud en la propia página de inicio de sesión del servicio, y la app recibe un access token limitado a los scopes que aceptaste. Se encarga de la autorización; OpenID Connect añade el inicio de sesión encima.
OAuth 2.0 vs OpenID Connect vs SAML 2.0
OAuth 2.0
OpenID Connect
SAML 2.0
Responde a
¿A qué puede acceder esta app?
¿Quién es este usuario?
¿Quién es este usuario?
Elemento principal
Access token
ID token (un JWT) más access token
Aserción XML
Especificación
RFC 6749 (IETF)
OpenID Connect Core 1.0
OASIS SAML 2.0
Participantes
Cliente, servidor de autorización, servidor de recursos
Relying party, proveedor OpenID
Proveedor de servicios, proveedor de identidad
Uso típico
Acceso a APIs, "conecta tu cuenta"
Botones "Iniciar sesión con", login en móvil y SPA
Inicio de sesión único en el trabajo
Antes de OAuth, conectar dos servicios solía significar escribir la contraseña de uno en el otro. OAuth lo sustituyó por tokens de vida corta y alcance limitado que solo se emiten después de que tú los apruebes. El generador de abajo crea un verifier y un challenge PKCE reales en tu navegador y construye la URL de autorización, para que veas cada parámetro que usa el flujo.
La app crea un code_verifier aleatorio, lo convierte en un code_challenge mediante un hash y te envía al servidor de autorización con ese challenge, su client_id, los scopes y un valor state.
Inicias sesión en la página del servidor de autorización y apruebas los scopes.
El servidor redirige de vuelta al redirect_uri de la app con un authorization code de vida corta y el mismo state.
La app comprueba state y luego envía por POST el code y el code_verifier original al token endpoint.
El servidor calcula el hash del verifier, lo compara con el challenge guardado y devuelve un access token que la app envía a la API.
Usa el flujo authorization code con PKCE tanto en aplicaciones de una sola página como en apps móviles y apps de servidor.
Envía y comprueba siempre state, que la especificación de OAuth recomienda para prevenir la falsificación de peticiones entre sitios.
Pide los scopes más limitados que basten para la tarea; la gente aprueba antes las solicitudes pequeñas.
Registra redirect URIs exactos. Los comodines y las redirecciones abiertas son una forma clásica de robar tokens.
Guarda los client secrets solo en el servidor. Una app de navegador o móvil no puede mantener un secreto.
Preguntas frecuentes
¿OAuth es autenticación o autorización?
Autorización. Un access token dice qué puede hacer una app, no quién es el usuario, y puede que las APIs ni siquiera te lo digan. Cuando necesites la identidad de la persona, usa OpenID Connect, que devuelve un ID token firmado con claims como sub, iss, aud y exp.
¿Qué es PKCE y lo necesito?
PKCE (RFC 7636) vincula el authorization code a la app que inició el flujo. La app envía primero el hash de un secreto aleatorio y después el propio secreto, así que un code robado no sirve de nada. Usa S256, que los servidores deben admitir, en lugar de plain.
¿Qué diferencia hay entre OAuth y SAML?
SAML es un estándar más antiguo basado en XML en el que un proveedor de identidad envía una aserción firmada sobre el usuario a un proveedor de servicios, sobre todo para el inicio de sesión único empresarial en navegadores. OAuth emite tokens para acceder a APIs y funciona bien en apps móviles y APIs. OpenID Connect es el equivalente más cercano al inicio de sesión de SAML dentro del mundo OAuth.
¿Qué son los scopes?
Los scopes son los permisos que pide una app, escritos como una lista separada por espacios de strings que distinguen mayúsculas y que define el servidor de autorización, por ejemplo openid email o repo read:user. La pantalla de consentimiento los muestra, y el token solo cubre lo que se aprobó.
¿Debería seguir usando el flujo implicit?
No en proyectos nuevos. Devolvía los tokens en el fragmento de la URL, donde pueden filtrarse a través del historial y los logs. El flujo authorization code con PKCE ofrece la misma comodidad a las apps de navegador sin esa exposición.
Los cuatro roles
RFC 6749 define cuatro participantes. El propietario del recurso eres tú. El cliente es la app que pide acceso. El servidor de autorización comprueba quién eres y emite tokens. El servidor de recursos aloja la API que acepta esos tokens. A menudo una misma empresa gestiona ambos servidores, pero son funciones separadas.
Por qué existe el intercambio del code
La redirección de vuelta a la app pasa por el navegador, un lugar poco seguro para cualquier cosa valiosa. Por eso la redirección solo lleva un code de un solo uso, que la especificación recomienda que caduque en 10 minutos. El token real se obtiene en una llamada directa al token endpoint.
PKCE cierra el hueco que queda. Aunque un malware o un proxy que registra tráfico capture el code, no puede canjearlo sin el verifier, que nunca salió de la app.
Dónde encaja OpenID Connect
OpenID Connect es una capa fina sobre OAuth. Añade openid a los scopes, algo que la especificación OIDC hace obligatorio, y la respuesta del token también incluye un ID token: un JWT firmado que describe al usuario. Un nonce enviado en la solicitud y devuelto en el ID token protege contra ataques de repetición.
El flujo authorization code con PKCE
Cada paso y los parámetros que lleva
Paso
De a
Parámetros clave
1. Solicitud de autorización
De la app al servidor de autorización (redirección del navegador)
access_token, token_type, expires_in, refresh_token opcional (e id_token con OIDC)
6. Llamada a la API
De la app al servidor de recursos
Authorization: Bearer <access_token>
PKCE en código
Crear un verifier y un challenge S256 en el navegador
32 bytes aleatorios codificados en base64url dan un verifier de 43 caracteres, la longitud mínima que permite RFC 7636.
Intercambiar el code por tokens
Se ejecuta después de la redirección. Compara primero state y luego envía el verifier guardado junto con el code.
Generador de PKCE y URL de autorización
Crea un code_verifier nuevo y su code_challenge S256 con las funciones criptográficas de tu navegador, y luego monta una URL de autorización con tus ajustes. No se envía nada; el endpoint de abajo es un marcador que debes sustituir.
Endpoint de autorización
Scopes (separados por espacios)
Nuevo verifier
code_verifier ({n} caracteres, mantenlo en secreto hasta el paso 4)