Roles y flujos de OAuth que siguen vigentes

OAuth 2.0 reparte el trabajo entre cuatro papeles. El titular del recurso es la persona dueña de los datos. El cliente es la aplicación que quiere actuar en su nombre. El servidor de autorización autentica a la persona, le pregunta si concede el acceso y emite tokens. El servidor de recursos es la API que guarda los datos y acepta o rechaza cada petición según el token que recibe. Un token de acceso no dice quién es la persona: dice qué puede hacer un cliente concreto en una API concreta.

OpenID Connect se monta encima para resolver lo que OAuth no resuelve: iniciar sesión. Añade un token de identidad, firmado por el proveedor (el servidor de autorización, que aquí se llama proveedor OpenID), dirigido al cliente (que aquí se llama parte que confía) y que afirma quién es la persona y cuándo se autenticó. Confundir los dos tokens es el origen de buena parte de los fallos de este módulo.

Abre arquitectura.txt y ubica cada pieza en su papel.

El flujo implícito nació cuando las aplicaciones que corren enteras en el navegador no podían hacer peticiones a otro origen: el servidor devolvía el token de acceso directamente en la URL de vuelta, en el fragmento. Ese token queda expuesto en el historial, en extensiones del navegador y en cualquier redirección posterior, y no hay forma de atarlo a quien lo pidió. Hoy los navegadores permiten esas peticiones y existe PKCE, así que el motivo desapareció.

La práctica actual del estándar, publicada por el IETF en enero de 2025 como RFC 9700 (BCP 240), pide no usarlo y emplear el flujo de código. Se reconoce en la exportación de clientes por el tipo de respuesta que pide: token en lugar de code.

El otro flujo retirado es el de credenciales del titular (password): la aplicación pide usuario y contraseña en su propia pantalla y los cambia por un token. Con eso la contraseña pasa por un programa que no debería verla, el servidor no puede pedir un segundo factor ni avisar de nada, y la persona se acostumbra a escribir su clave fuera de la página de su proveedor. RFC 9700 dice que no debe usarse, y el borrador de OAuth 2.1, que sigue en trabajo en el IETF, ya ni lo incluye, igual que el implícito.

Lo que sigue vigente es corto: el flujo de código de autorización con PKCE para todo lo que actúa por una persona, el de credenciales del cliente para servicios que actúan en su propio nombre, el de autorización de dispositivo (RFC 8628) para aparatos sin navegador ni teclado cómodo, y el token de actualización para renovar sin volver a molestar a la persona.

Lee en notas-del-equipo.txt cómo obtiene su token el informe de ocupación y para quién trabaja. Un proceso que no actúa por ninguna persona no debería depender de la contraseña de una: si ella cambia la clave, se va de la empresa o activa un segundo factor, el informe se rompe, y mientras tanto todo lo que hace el informe queda registrado a su nombre.

Una aplicación de escritorio o móvil es un cliente público: cualquier secreto que lleve dentro se puede extraer del programa instalado. La guía del IETF para aplicaciones nativas (RFC 8252) pide que abran el navegador del sistema para la autorización, en lugar de pintar su propio formulario, y que reciban el código en una dirección local o en un esquema propio, protegidas con PKCE. Si el aparato no tiene navegador, el camino es el flujo de dispositivo.