Los flujos de OAuth 2.0 y cuál corresponde a cada aplicación

OAuth 2.0 (RFC 6749) separa a quien pide el permiso en dos familias según una sola pregunta: ¿puede guardar un secreto donde el usuario no llegue? Un servicio que corre en una máquina de la empresa sí puede, y se llama cliente confidencial. Una aplicación que corre dentro del navegador o dentro de un teléfono, no: todo lo que lleva dentro está al alcance de quien tenga el dispositivo, y se llama cliente público.

De esa pregunta sale el flujo. El flujo de código de autorización devuelve al navegador un código de un solo uso que después se cambia por el token en una llamada aparte. Para los clientes públicos se le añade PKCE (RFC 7636, septiembre de 2015), que hace que ese código solo sirva a quien lo pidió: la aplicación inventa un valor al empezar y lo demuestra al canjear. La práctica vigente de seguridad de OAuth 2.0, publicada por la IETF como RFC 9700 en enero de 2025, recomienda el código con PKCE como camino general.

Lo que el evaluador compara, entonces, son dos columnas del inventario: dónde corre la aplicación y qué flujo tiene configurada.

Uno de los flujos originales entregaba el token de acceso directamente en la dirección a la que el navegador vuelve. Era cómodo para las aplicaciones que viven en una página, y es justo lo que hoy se desaconseja: lo que viaja en la dirección queda en el historial, en el encabezado que el navegador manda al enlace siguiente y en los registros de cualquier intermediario. La práctica vigente desaconseja ese flujo y empuja a todas las aplicaciones de navegador al código con PKCE.

Abre el laboratorio y cruza el inventario con la tabla de flujos.

Un cliente público con flujo de código y sin PKCE recibe un código que cualquiera que lo intercepte puede canjear: no hay nada que ate ese código a quien lo pidió. En un teléfono eso importa porque el sistema operativo entrega la respuesta a la aplicación registrada para ese destino, y el registro no siempre es exclusivo. PKCE cierra ese hueco sin añadir ningún secreto guardado.

Vuelve al laboratorio y mira las columnas de tipo de cliente y de PKCE.

Antes de escribir hace falta una cifra. En el informe no se dice «hay flujos antiguos»: se dice cuántas aplicaciones del inventario están configuradas con un flujo que la práctica vigente desaconseja, y se nombran. La tabla de flujos trae la columna que lo decide.

Ya tienes la aplicación del teléfono sin la prueba de posesión del código. Falta decidir cómo se redacta: qué se vio en la evidencia, qué tendría que ocurrir para que hiciera daño y cuál es la corrección. Lo que no se vio no se escribe.