OAuth 2.1 Ya Jubila Oficialmente a RFC 6749: Estas Son las Reglas Nuevas

El borrador que ya no es un borrador

El 3 de septiembre se publicó la revisión 16 del draft de OAuth 2.1 en el IETF, y el texto no deja lugar a dudas: reemplaza y declara obsoletos el RFC 6749 (OAuth 2.0) y el RFC 6750 (Bearer Tokens). Llevamos años usando "OAuth 2.0 + parches" — PKCE aquí, BCP de seguridad allá — y OAuth 2.1 es, básicamente, la consolidación de todos esos parches en una sola especificación.

A la vez, en la cola de publicación del RFC Editor hay otro documento importante para los que trabajamos con tokens: draft-ietf-oauth-rfc8725bis, la actualización de las mejores prácticas de JWT. Cuando salga, será la referencia oficial de cómo validar un JWT en 2026.

Repasemos lo que cambia en la práctica.

---

Lo que OAuth 2.1 cambia respecto a 2.0

PKCE es obligatorio para todos

El Proof Key for Code Exchange deja de ser "recomendado para clients públicos" y pasa a ser obligatorio en el authorization code flow, incluidos clients confidenciales. Si tu proveedor todavía lo marca como opcional, actívalo igualmente.

El implicit grant desaparece del mapa

Ya nadie debería usar response_type=token, pero OAuth 2.1 lo elimina directamente de la especificación. Lo mismo ocurre con Resource Owner Password Credentials (la contraseña del usuario pasando por tu server): fuera.

Redirect URIs exactas

Nada de comodines ni de comparaciones laxas: la redirect URI registrada debe coincidir carácter a carácter con la de la petición. Esto cierra una clase entera de ataques de open redirect.

Refresh tokens con rotación o sender-constrained

Los refresh tokens deben ser de un solo uso (rotación con detección de robo) o estar ligados al client con DPoP/mTLS. Un refresh token robado ya no debería ser reutilizable.

Bearer tokens fuera de la query string

RFC 6750 permitía pasar access_token como parámetro de URL. En la práctica acababa en logs, historiales y referers. OAuth 2.1 lo prohíbe: header Authorization o nada.

---

Y mientras tanto, el nuevo BCP de JWT

El RFC 8725 (JWT Best Current Practices) está siendo reemplazado por una versión actualizada que ya está en la fase final de publicación. Los puntos que todo el mundo debería interiorizar:

• Rechaza alg: none. Siempre. Sin excepciones.
• Explicita el algoritmo esperado: no dejes que la librería acepte lo que diga el header del token. El ataque clásico de confusión RS256→HS256 sigue vivo en librerías mal usadas.
• Valida iss, aud y exp explícitamente, no solo la firma.
• Cuidado con kid: es un string controlado por el atacante. Si lo usas para buscar la clave en un path o en una query SQL, tienes un vector de inyección.

Puedes inspeccionar exactamente qué alg, kid y claims llevan tus tokens con nuestro decodificador JWT — es la forma más rápida de auditar qué está firmando realmente tu proveedor de identidad.

---

Checklist para tu aplicación

1. Authorization code + PKCE en todos los flows interactivos. Si tienes implicit por ahí, migra hoy.
2. Redirect URIs exactas registradas en tu IdP; audita las que tienen wildcards.
3. Refresh token rotation activada; revisa si tu IdP la soporta (la mayoría ya sí).
4. Validación JWT explícita: algoritmo fijado en el código, claims verificados, none rechazado.
5. Tokens nunca en URLs: ni access tokens ni refresh tokens en parámetros de query.

OAuth 2.1 no inventa nada nuevo: simplemente convierte en norma lo que llevábamos siete años diciendo que "había que hacer". La diferencia es que ahora ya no hay excusa.