Resumen

  • La revisión 04 de OAuth for First-Party Applications propone un endpoint HTTPS que puede emitir un código, pedir al cliente nativo más información del usuario o exigir el retorno al navegador. Evitar la redirección convierte al binario instalado, su procedencia, su interfaz y su obediencia al riesgo en parte de la superficie de confianza.
  • auth_session, PKCE y DPoP pueden enlazar continuidad de protocolo con una instancia y una clave. No prueban que el binario sea realmente de primera parte, que la persona haya visto el desafío previsto, que las apps hermanas den las mismas señales, que el fallback ocurriera cuando debía ni que el resultado externo se completara.

El usuario introdujo un código de un solo uso en la app del banco. La aplicación lo envió al servidor y recibió un authorization code por back channel. No apareció ninguna ventana externa. La fricción disminuyó, pero la autoridad de presentación se desplazó.

OAuth 2.0 for First-Party Applications define el Authorization Challenge Endpoint. El cliente puede aportar login hints, desafíos passkey firmados, códigos MFA u otros datos específicos. El servidor puede emitir el código, responder insufficient_authorization para continuar el diálogo o devolver redirect_to_web y recuperar la interacción directa en un navegador.

La revisión 04 es un Internet-Draft activo del grupo OAuth, fechado el 1 de julio de 2026, con vencimiento el 2 de enero de 2027 y destino Standards Track. No es un RFC. Las fuentes no demuestran registro IANA final, interoperabilidad, despliegue, cobertura de attestation, reducción de phishing ni resultado autorizado.

El endpoint nativo desplaza la presentación

En el flujo clásico, el servidor controla la página donde se introducen credenciales. Aquí, un cliente con alta confianza controla gran parte de la ceremonia. Envía por HTTPS los parámetros OAuth y los datos recogidos. El endpoint admite extensiones, aunque algunos parámetros de significado web carecen de equivalente claro y su tratamiento queda fuera del borrador.

El servidor decide si la información acumulada basta. La app puede decidir cómo muestra la solicitud, qué componente recibe el secreto, cómo explica un error y qué endpoint propietario usa para los pasos intermedios. Los formatos de esos pasos, los challenge schemas y la secuencia están explícitamente fuera de alcance; hacen falta perfiles para obtener interoperabilidad.

La evidencia debe conservar build, instancia instalada, perfil, tipo de solicitud, clase de entrada sin el valor secreto, scopes, versión de policy, respuesta y próximo paso. Un código prueba que el servidor generó un artefacto de concesión, no qué pantalla vio la persona antes.

Ser de primera parte es una relación

Antes de continuar, el servidor MUST verificar la “first-partyness”. La app ha de estar controlada por la misma entidad que el servidor y el usuario debe entender que pertenecen a la misma entidad. La forma de verificarlo queda fuera de especificación.

La attestation del sistema o de la tienda puede identificar software, firma, clave o canal. Attestation-Based Client Authentication y Dynamic Client Registration añaden coordenadas. Ninguna pieza fusiona control corporativo, custodia de distribución, integridad del binario, posesión de clave y reconocimiento humano de la marca.

Una app firmada puede estar desactualizada o comprometida. Un package auténtico puede dibujar una solicitud engañosa. Una clave DPoP puede pertenecer a una copia no prevista si enrollment y policy no fijan la instancia. Una interfaz familiar se puede imitar.

El recibo debe separar publisher, distributor, attestation issuer, nonce, freshness, policy y estado de la instancia de client_id, auth_session y el código. “Primera parte verificada” es una conclusión trazable, no un campo que se verifica solo.

auth_session es contexto opaco llevado por la app

auth_session relaciona solicitudes posteriores de la misma instancia, como una cookie cuyos envíos gestiona la aplicación. Es opaco y el servidor protege su contenido. Cualquier respuesta puede rotarlo; el cliente debe actualizarlo, conservarlo incluso después del código y eliminarlo al cerrar sesión.

El valor debe ser único; si es aleatorio, el proyecto recomienda 256 bits de entropía. Debería ligarse al dispositivo. No hay duración normativa: el servidor puede expirar o revocar por tiempo o riesgo, y el cliente no debe depender de una vida concreta.

La auditoría necesita generación, predecesor, instancia, contexto, clave DPoP, etapa, creación, último uso, motivo de rotación, logout y final. No debe registrar el valor opaco. Una sesión aceptada solo prueba que el servidor continuó un contexto; no demuestra la honestidad de pantallas anteriores ni la continuidad de la persona.

DPoP mantiene la clave, no la interfaz

La revisión 04 recomienda sender-constrained tokens y describe DPoP para challenge, code, token, resource y auth_session. El servidor puede exigir la misma clave desde la primera petición y verificar la posesión privada en cada continuación.

Eso reduce el replay de una sesión o código robado. Pero key continuity no es app provenance. DPoP no dice quién autorizó enrollment, qué package presentó la pantalla, si la instancia sigue íntegra, si la policy confía todavía en ella o si el usuario consintió ese scope.

Los estados deben ser independientes: coincidencia DPoP, attestation aceptada, registration activa, policy de primera parte, perfil de prompt y autorización del usuario. Un solo indicador “cliente vinculado” es insuficiente.

redirect_to_web es una transición de seguridad

El servidor puede devolver redirect_to_web por riesgo, método no disponible, recuperación o excepción. El cliente inicia un nuevo code flow en un external user agent, quizá usando un PAR request_uri.

Si la solicitud nativa inicial no incluyó PKCE code_challenge, el servidor no debe retornar ese request_uri. El fallback debe respetar RFC 8252, RFC 9700 y la continuidad del issuer de RFC 9207.

Hay que guardar el trigger, risk band, método o recovery reason, PKCE, issuer, referencia, navegador externo, return URI, state y callback. Haber abierto el navegador no prueba haber llegado al servidor correcto; seguir nativo no prueba que el riesgo lo permitía.

Ignorar redirect_to_web, reintentar nativamente o usar una webview incrustada que se haga pasar por browser cruza la policy. Las pruebas deben seguir la transición desde la respuesta hasta el callback ligado al emisor.

Varias apps multiplican la decisión

El texto exige experiencia idéntica entre apps de primera parte. No es solo branding. Varias formas legítimas de introducir secretos enseñan al usuario a aceptar más imitaciones. Cada implementación añade parser, storage, accessibility, SDK y fallos.

Un SDK común reduce divergencia y concentra dependencia. Firma, versión, rollout y retirada de emergencia forman parte del control. La identidad debe abarcar lenguaje de solicitudes, señales de origen, tratamiento de secretos, capturas, accesibilidad, error, fallback, session storage y redaction, no solo estilo.

El servidor necesita un inventario que relacione cada client y attestation policy con entidad, publisher, canal, builds, SDK, perfil y retiro. Una app hermana más débil no debe heredar confianza por marca.

El código no prueba el efecto

Authorization code, PKCE, DPoP, auth_session, step-up y access token son coordenadas diferentes. El code lleva la concesión; PKCE lo enlaza a verifier; DPoP al key; la session al contexto; step-up describe autenticación adicional; el token presenta autorización al resource server.

Ninguno demuestra la consecuencia. La API puede denegar, restringir o aceptar sin completar una transferencia posterior. El usuario puede cerrar la app, un pago puede revertirse y una credencial emitida no instalarse. El recibo de realidad debe registrar decisión del recurso y resultado observado después de OAuth.