Flujos de OAuth 2.0
Concesiones de autorización y tokens.
Flujos de OAuth 2.0 es una lección gratuita de Cyber Security Academy en CoddyKit. Esta es la lección 1 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Cyber Security Academy, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Cyber Security Academy incluye 4 lecciones en total.
Qué resuelve realmente OAuth 2.0
OAuth 2.0 es un marco de autorización delegada. Permite que un usuario conceda a una aplicación de terceros un acceso limitado a sus recursos en otro servicio sin compartir su contraseña.
- Se trata de autorización (lo que una aplicación puede hacer), no de autenticación (quién es el usuario).
- La aplicación recibe un
access_tokencon un alcance definido, nunca las credenciales del usuario.
Los defensores deben recordar que OAuth por sí solo no demuestra la identidad. Tratar un token de acceso como prueba de inicio de sesión es un error clásico que OIDC aborda.
Los cuatro roles
Todo flujo de OAuth implica cuatro roles. Asignarlos correctamente es esencial para el modelado de amenazas.
- Propietario del recurso: el usuario que posee los datos.
- Cliente: la aplicación que solicita acceso.
- Servidor de autorización (AS): emite tokens después del consentimiento.
- Servidor de recursos (RS): la API que contiene los datos protegidos y valida los tokens.
Entre estos roles existen límites de confianza. Un cliente comprometido o un AS demasiado permisivo debilita toda la cadena.
Roles:
Resource Owner -> grants consent
Client -> requests + uses tokens
Authorization Server -> issues tokens
Resource Server -> validates tokensFlujo de código de autorización
El flujo de código de autorización es el recomendado para aplicaciones web y móviles. Separa la redirección visible para el usuario del intercambio secreto de tokens.
- El usuario es redirigido al AS para autenticarse y dar su consentimiento.
- El AS devuelve un
codede corta duración a la URI de redirección registrada. - El cliente intercambia el código (en el servidor) por tokens a través de un canal alternativo.
Como los tokens se obtienen a través del canal alternativo, nunca aparecen en la barra de direcciones ni en el historial del navegador.
GET /authorize?response_type=code
&client_id=app123
&redirect_uri=https://app.example/cb
&scope=read:profile
&state=xyz
// then back-channel:
POST /token grant_type=authorization_code&code=...PKCE: prueba de clave para el intercambio de códigos
PKCE (RFC 7636) refuerza el flujo de código de autorización y ahora se recomienda para todos los clientes, incluidos los confidenciales.
- El cliente genera un
code_verifieraleatorio y envía su hash comocode_challenge. - Al intercambiar el código por tokens, debe presentar el verificador original.
Esto vincula el código con el solicitante original e impide que un atacante que intercepte el código de autorización lo canjee.
code_verifier = random 43-128 chars
code_challenge = BASE64URL(SHA256(verifier))
/authorize ... &code_challenge=...&code_challenge_method=S256
/token ... &code_verifier=<original>Flujo de credenciales del cliente
El flujo de credenciales del cliente se utiliza para el acceso entre máquinas, cuando no interviene ningún usuario (por ejemplo, un servicio backend que llama a una API).
- El cliente se autentica con sus propias credenciales y recibe un token de acceso.
- Normalmente no hay consentimiento del usuario ni token de actualización.
Limite estrictamente el alcance de estos tokens y rote los secretos del cliente. Nunca utilice este flujo para suplantar a usuarios finales.
POST /token
grant_type=client_credentials
client_id=service-a
client_secret=***
scope=orders:readTokens de acceso frente a tokens de actualización
OAuth emite dos tipos principales de tokens, con duraciones y reglas de gestión muy diferentes.
- Token de acceso: de corta duración, se envía al servidor de recursos en cada llamada. Trátelo como una credencial de portador.
- Token de actualización: de larga duración, se utiliza únicamente contra el AS para obtener nuevos tokens de acceso.
Los tokens de actualización son muy valiosos. Almacénelos de forma segura, vincúlelos al cliente y admita su revocación.
POST /token
grant_type=refresh_token
refresh_token=<long-lived>
client_id=app123Tokens de portador y transporte
La mayoría de los tokens de acceso son tokens de portador: cualquiera que tenga el token puede utilizarlo, como si fuera dinero en efectivo.
- Transmítalos siempre mediante TLS; nunca en URL, donde pueden filtrarse en registros y encabezados Referer.
- Envíelos mediante el encabezado
Authorization. - Considere utilizar tokens vinculados al remitente (DPoP, mTLS) para API de alto riesgo.
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...
// AVOID:
GET /api/data?access_token=... // leaks in logsLa concesión implícita está obsoleta
La concesión heredada Implicit devolvía los tokens directamente en el fragmento de la URI de redirección. Ahora está desaconsejada por las BCP de seguridad de OAuth 2.0 y se eliminó en OAuth 2.1.
- Los tokens se filtraban a través del historial del navegador, los encabezados Referer y los registros.
- Al no existir un canal de retorno, la autenticación del cliente era más débil.
Utilice el flujo de código de autorización con PKCE para las SPA.
El parámetro state y CSRF
El parámetro state protege el paso de redirección frente a CSRF. El cliente genera un valor aleatorio, lo almacena en la sesión y lo verifica en el callback.
- Si el
statedevuelto no coincide, rechace la respuesta. - Esto impide que un atacante inyecte su propio código de autorización en la sesión de una víctima.
before: session.state = randomNonce()
/authorize ... &state=<nonce>
on callback:
if (req.state !== session.state) reject()Scopes y mínimo privilegio
Los scopes expresan la granularidad del acceso que concede un token. Aplique el principio de mínimo privilegio en cada paso.
- Solicite únicamente los scopes que necesita la funcionalidad (
read:profile, noadmin). - Los servidores de recursos deben aplicar el scope en cada endpoint, no limitarse a confiar en que el token sea válido.
El consentimiento demasiado amplio es un riesgo común en la práctica: los usuarios aprueban aplicaciones que solicitan mucho más de lo necesario.
Errores comunes de configuración de OAuth
La mayoría de los incidentes de OAuth se deben a la configuración, no al protocolo en sí.
- Las redirecciones abiertas o la coincidencia flexible de redirect_uri permiten a los atacantes robar códigos.
- La ausencia de
stateo PKCE permite CSRF e inyección de códigos. - Tokens de acceso de larga duración sin revocación.
- Tratar un token de acceso como una aserción de autenticación.
Registre las URI de redirección exactas y valídelas estrictamente.
redirect_uri allowlist:
EXACT: https://app.example/cb
NOT: https://app.example/* (too broad)Comprobación rápida: protección de la autenticación de una SPA
Seleccione el flujo correcto y moderno para el escenario siguiente.
Resumen: flujos de OAuth 2.0
Conclusiones principales:
- OAuth 2.0 es autorización delegada, no autenticación.
- Hay cuatro roles: propietario del recurso, cliente, servidor de autorización y servidor de recursos.
- El código de autorización + PKCE es la opción predeterminada para aplicaciones web, móviles y SPA.
- La concesión Client Credentials cubre el acceso entre máquinas.
- Proteja el sistema con
state, coincidencia estricta de las URI de redirección, tokens de acceso de corta duración y TLS en todas partes. - Las concesiones Implicit y Password están obsoletas.
Preguntas frecuentes
¿La lección «Flujos de OAuth 2.0» es gratis?
Sí — el texto completo de «Flujos de OAuth 2.0» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Cyber Security Academy, actualiza a CoddyKit PRO. El curso de Cyber Security Academy incluye 4 lecciones en total.
¿Qué aprenderé en «Flujos de OAuth 2.0»?
Concesiones de autorización y tokens. Practicas Cyber Security Academy con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar Cyber Security Academy?
No se requiere experiencia previa. Cyber Security Academy en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 1 de 4.
¿Cuánto tiempo toma la lección «Flujos de OAuth 2.0»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de Cyber Security Academy?
Sí. Cada lección de Cyber Security Academy incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.