Inicio de sesión en el móvil: OAuth, navegador del sistema y PKCE

La guía de OAuth para aplicaciones nativas (RFC 8252) exige que la app abra la petición de autorización en un agente de usuario externo, es decir, el navegador del sistema, y desaconseja los agentes incrustados: una vista web dibujada dentro de la propia app. La razón es de confianza. En una vista incrustada, el código de la app controla la pantalla: puede observar lo que la persona teclea, y la persona no tiene dirección visible que comprobar. En el navegador del sistema, la app queda fuera de esa pantalla, y además se reutiliza la sesión que la persona ya tenga abierta con el proveedor.

Para quien evalúa, el lanzador es lo primero que se mira en la traza de una petición de autorización: dice si la app puede ver o no la contraseña.

Un cliente público no tiene secreto con el que demostrar que es él quien canjea el código de autorización. PKCE (RFC 7636) lo resuelve con un secreto de un solo uso: la app inventa un verificador al azar, manda en la petición de autorización una transformación suya (el desafío) y, al canjear el código, entrega el verificador. El servidor aplica la transformación y compara; quien interceptó el código no tiene el verificador. La transformación recomendada es S256 (el desafío es el resumen SHA-256 del verificador). El estándar prevé una segunda, que manda el verificador sin transformar, pensada solo para clientes que no pueden calcular el resumen; una app moderna sí puede.

Abre cliente-registrado.txt. Un servidor que acepta el método débil para un cliente que puede usar el fuerte deja abierta una puerta que el cliente no necesita.

Dos compilaciones de la misma app pueden comportarse distinto. La traza de la petición de autorización guarda un campo lanzador, y las dos versiones de prueba lo rellenan con valores diferentes. Esa diferencia es un hallazgo atribuible: no se reporta «la app», se reporta la versión y el campo que lo demuestra, para que el equipo de desarrollo sepa qué compilación corregir y cuál ya está bien.

Abre traza-autorizacion.txt y compara las dos entradas.

Que el cliente use PKCE no sirve de nada si el servidor no lo exige. El registro del servidor en el endpoint de canje anota, por evento, si llegó el verificador y qué respondió el servidor. Un código canjeado sin verificador y aceptado demuestra que la protección es voluntaria: quien intercepte un código podría canjearlo. Es un hallazgo del servidor de acceso, no de la app, y se cita con el identificador del evento que lo prueba.

Compara con la política del cliente que cierra el archivo canje-del-codigo.txt.

Cuando el navegador termina la autorización, devuelve el código a la app por una dirección de retorno. Hay tres formas: un enlace https que el sistema verifica contra el dominio, un esquema propio (nogalera-pagos:/retorno) y una dirección de bucle local. RFC 8252 recomienda la primera donde sea posible, porque el sistema garantiza al servidor qué app la recibe. Con un esquema propio, otra app instalada en el mismo aparato puede declarar el mismo esquema y recibir el código; PKCE es lo que lo vuelve inútil para ella, pero es una segunda barrera, no una excusa.

El cliente de Nogalera tiene registradas las dos primeras. Se recomienda retirar la heredada cuando ya no haya versiones que la usen.