Resumen

  • draft-ietf-oauth-deferred-token-response-00 representa una petición de token pendiente mediante un deferral_code ligado al emisor; el código no otorga acceso.
  • El endpoint de revocación devuelve HTTP 200 tanto cuando cancela como cuando no cambia nada. El anuncio de compatibilidad y el poll que devuelve access_denied son pruebas distintas.
  • Un token ya entregado es otra credencial. Cancelar el código diferido no lo revoca ni demuestra que la operación del recurso haya terminado.

Una respuesta diseñada para no confesar

El RFC 7009 evita que el endpoint de revocación se convierta en un oráculo. Una entrada inválida no provoca una respuesta reveladora. Esta protección es razonable, pero impide usar el estado HTTP como sustituto del estado interno.

La revisión 00 de Deferred Token Response lleva la cuestión a flujos en los que el servidor no puede decidir inmediatamente si expide un token. Puede haber revisión humana, análisis de fraude o verificación externa. Si el cliente admite finalización diferida y el servidor la elige, el endpoint de token contesta HTTP 400 con authorization_pending, un código opaco, una vida útil y un intervalo de consulta.

No es un token disfrazado. No concede acceso al recurso. Representa una sola solicitud pendiente y, si la petición original estaba ligada mediante DPoP o mTLS, conserva la misma ligadura. El borrador es trabajo en curso del grupo OAuth, no una norma publicada ni una medición de implementaciones.

Dos expires_in pertenecen a objetos distintos

En la respuesta diferida, expires_in gobierna el código de diferimiento. Cuando caduca, la consulta obtiene expired_token. Si más tarde se expide un token de acceso, la respuesta final puede usar el mismo nombre para la vida de ese token. Una interfaz que muestre un único reloj habrá perdido la identidad del objeto.

El valor interval también forma parte del estado retenido. Solo aparece al principio. El cliente debe respetarlo durante toda la espera y ampliarlo al menos cinco segundos ante slow_down. Guardar la última respuesta sin la primera hace imposible auditar la cadencia.

Una constancia precisa vincula tiempo, credencial y actor. No basta con «vence a las 17:00» si no sabemos qué vence y qué autoridad controla esa caducidad.

El callback solo despierta al cliente

El servidor puede enviar una notificación HTTPS cuando la petición llega a cualquier estado final. El cuerpo señala el código, pero no transporta token ni resultado. Éxito, error y cancelación despiertan al mismo consumidor.

Un token de notificación por solicitud permite autenticar la llamada. Sin él, el cliente necesita otra protección y debería considerar el callback orientativo hasta confirmar mediante poll. Aun autenticado, el aviso dice quién llamó, no qué decisión encontrará el cliente.

Por eso el borrador recomienda mantener las consultas según interval. La notificación reduce latencia; la consulta soporta mensajes perdidos, retrasados o bloqueados. Convertir el callback en veredicto destruye esa separación.

La cancelación tiene una respuesta y varios resultados

El cliente presenta el código exacto en el endpoint de revocación. Si el servidor lo reconoce y pertenece al cliente autenticado, cambia atómicamente la solicitud a cancelada, suprime el callback que todavía no empezó a enviarse y hace que las siguientes consultas respondan access_denied.

El mismo 200 aparece si el código es desconocido, pertenece a otro cliente, ya fue canjeado, ya se canceló o caducó. En esos casos no cambia nada. La indistinguibilidad conserva privacidad, pero borra del acuse la semántica que necesita la operación.

DTR define la metainformación revocation_endpoint_token_type_values_supported. Un servidor compatible enumera el tipo deferral-code. Si no lo anuncia, seguirá respondiendo 200 según RFC 7009; el borrador advierte que omitir esta comprobación puede dejar la petición viva en silencio.

La evidencia debe conservar el orden: instantánea de compatibilidad, solicitud de cancelación, respuesta de transporte y poll posterior. Solo el access_denied observado después coloca el estado cancelado al alcance del cliente.

La entrega del token parte la carrera

Puede ocurrir que la revisión ya se resolviera positivamente pero el token aún no saliera. Una cancelación en ese intervalo produce el estado «canjeado y después cancelado»: no se entrega token y la siguiente consulta recibe access_denied.

Si el token ya llegó, la revocación del código no debe revocarlo como efecto lateral. Son credenciales independientes. Cortar el acceso exige una solicitud específica para el token y, cuando importa la consecuencia, una prueba en el servidor de recursos.

También puede haber un callback en vuelo. El servidor solo debe suprimir el que todavía no empezó. Un aviso tardío puede coexistir con una cancelación correcta; el consumidor no debe interpretarlo como reapertura ni como aprobación.

Por eso «cancelado» necesita un complemento: pendiente, resuelto sin entrega o token entregado. Esa frontera decide qué queda por hacer.

La autorización puede envejecer antes que el código

La espera puede durar horas o días. El titular puede retirar el consentimiento, la sesión puede terminar o el cliente puede ser desactivado. Antes de expedir, el servidor debe revisar esas condiciones. Una verificación externa favorable no obliga a emitir si la autoridad actual cambió.

Después, el recurso aplica alcance y política local. Un token válido no prueba que aceptó una operación. Y una admisión no prueba que la operación empresarial terminó. Cada resultado tiene su observador.

Un recibo mínimo sin registrar el secreto

La constancia local debería guardar el emisor y el digest de sus metadatos, la identidad del cliente y la referencia a la clave vinculante, una correlación unidireccional del código, su caducidad e intervalo, los intentos de cancelación, el poll final, el estado del callback y si la respuesta de token cruzó la frontera de entrega.

No hace falta verter el código secreto en logs; el borrador pide tratarlo como un secreto comparable al refresh token. Si hubo entrega, se añade la revocación del token. Si el riesgo era una acción, se añade admisión y resultado controlado.

Esto es una especificación inicial mínima para comparar evidencia, no un registro central. La doctrina de capas de Lu Heng mantiene separados el mensaje 200, la transición interna, el error observado, la vida del token y la operación ejecutada. La prueba mejora al acercarse a código en funcionamiento, no al multiplicar copias de la primera respuesta.

Fuentes

  1. Deferred Token Response rev00
  2. Historial de DTR
  3. DTR rev00 HTML
  4. DTR rev00 texto
  5. RFC 6749 — OAuth 2.0
  6. RFC 7009 — Revocación OAuth
  7. RFC 8628 — Device Authorization Grant
  8. RFC 8693 — Token Exchange
  9. RFC 8705 — OAuth mTLS
  10. RFC 9449 — OAuth DPoP
  11. RFC 9700 — Prácticas de seguridad OAuth
  12. Parámetros OAuth de IANA
  13. Lu Heng — Minimum Initial Specification
  14. Lu Heng — On Reality Layers
  15. Lu Heng — Running Code Primary