Una prueba DPoP muestra que se usó una clave. No otorga derechos a un inquilino de MSP

Una prueba DPoP muestra que se usó una clave. No otorga derechos a un inquilino de MSP

La frase que un MSP oye del cliente después de que alguien active los «tokens restringidos al remitente» es: «DPoP está activado, así que se aplica el límite entre inquilinos (tenants)». La respuesta corta es no. El RFC 9449, sección 4, consultado el 4 de octubre de 2026, dice que una prueba DPoP demuestra la posesión de una clave y que, por sí sola, no es un mecanismo de autenticación ni de control de acceso. La misma sección dice que un JWT de prueba DPoP válido no basta por sí solo para tomar decisiones de control de acceso.

El resumen de esa página tiene una función más acotada. Describe cómo restringir al remitente los tokens de OAuth 2.0 con una prueba de posesión a nivel de aplicación, lo que permite detectar la reutilización (replay) de tokens de acceso y de actualización. Detectar la reutilización no es un derecho de inquilino. No es una decisión de autorización del producto. Un control que advierte que un token se presenta de nuevo sigue siendo un control sobre ese token, no un registro de qué clientes puede tocar un MSP.

El resto del artículo explica qué puede significar la prueba, qué distinciones afines establecen NIST SP 800-63-3 y la OWASP Authorization Cheat Sheet, con qué cuestiones cercanas no debe confundirse y por qué un token vinculado a un inquilino sigue sin ser un derecho. Se mantiene al nivel del estándar: aquí no hay pruebas de ejemplo, claves, cadenas de token ni construcción de cabeceras.

La sección 4 es el punto que ningún lector debería pasar por alto, así que aquí va de nuevo con otras palabras. Una prueba DPoP muestra la posesión de una clave. Por sí sola no es autenticación. Por sí sola no es un mecanismo de control de acceso. Un JWT de prueba válido no basta por sí solo para una decisión de control de acceso. Cuando una prueba se presenta junto con un token de acceso vinculado a la clave, el RFC remite a la sección 7.1 para ese caso, y la garantía que añade es que el cliente que presenta el token posee la clave. Una garantía sobre la presentación sigue sin ser un mapa de los clientes del MSP. Poseer la clave no nombra un inquilino, no enumera los usuarios de ese inquilino y no aprueba una acción sobre un objeto dentro del inquilino.

El resumen y la introducción, en conjunto, describen un mecanismo que restringe al remitente los tokens de acceso y de actualización y que admite la detección de reutilización. La introducción también dice que DPoP en sí no se usa para autenticar al cliente, aunque puede usarse con independencia de cómo se autentique el cliente. Los clientes públicos son un caso de uso principal en esa página. Es lo contrario de «DPoP inició la sesión del usuario». Una prueba que viaja con un token es una restricción sobre quién puede presentar el token. No es el inicio de sesión ni el directorio.

La sección 3, a grandes rasgos: la prueba es un JWT firmado que se envía con la solicitud, y el servidor de recursos sigue teniendo que considerar el token válido en todos los demás aspectos. «Válido en todos los demás aspectos» es el recordatorio para el comprador: la firma y la posesión no sustituyen la caducidad, la audiencia ni la decisión propia de la aplicación. Son controles distintos, y una prueba no los absorbe.

La sección 2 plantea el objetivo como una clase de defensa. La vinculación pretende limitar el uso de un bearer token filtrado por parte de quienes no poseen la clave. Los bearer tokens los puede usar cualquiera que los tenga; DPoP pretende restringir al remitente. El RFC también dice que DPoP no sustituye a un transporte seguro.

Merece la pena nombrar dos límites que recogen las consideraciones de seguridad del RFC. Una prueba no protege la integridad de toda la solicitud. Un nonce proporcionado por el servidor es una forma opcional de que los servidores limiten cuánto tiempo sigue siendo utilizable una prueba. Un MSP que necesite un diseño de nonce debería obtenerlo de una revisión de la implementación de su propia pila.

NIST SP 800-63-3 es un texto afín y aquí sirve de diccionario. La página de SP 800-63-3, consultada el 4 de octubre de 2026, dice que la autenticación establece la confianza en que el solicitante posee un autenticador vinculado a la credencial. La autenticación no determina autorizaciones ni privilegios de acceso; esa es una decisión aparte, fuera del alcance de esas directrices. Las relying parties pueden usar una identidad autenticada y atributos, además de otros factores, para tomar decisiones de autorización. La relying party es el árbitro final de si una aserción cumple sus criterios de acceso al sistema, con independencia de los niveles de garantía que definen esas directrices. Este artículo solo usa esa distinción; los niveles de garantía son otro tema.

La OWASP Authorization Cheat Sheet, consultada el 4 de octubre de 2026, define la autorización como la verificación de que una acción solicitada está aprobada para una entidad concreta, y dice que la autorización es distinta de la autenticación. Defiende la denegación por defecto, el mínimo privilegio y una comprobación en cada solicitud. Advierte de que la comprobación integrada de un framework puede ser la equivocada para la aplicación. Esa es la frase sobre el punto de decisión para este artículo: una prueba de protocolo no es la aprobación, por parte de la aplicación, de una acción limitada a un inquilino. Una biblioteca que acepta una prueba ha hecho el trabajo de la biblioteca. La aplicación todavía tiene que decidir si este llamante puede tocar este objeto.

Pongamos las tres juntas para un MSP. DPoP puede restringir qué clave puede presentar un token. NIST dice que ni siquiera una autenticación correcta es la autorización. OWASP dice que la decisión de autorización corresponde a la aplicación, con denegación por defecto, en cada solicitud. Ninguna de las tres es un registro de derechos del inquilino cliente. Un derecho de inquilino es un registro del producto: qué cliente, qué acción, qué objeto. Una prueba, un autenticador y un principio de una cheat sheet pueden orientar cómo se comprueba ese registro. No son el registro.

Esta no es una FAQ sobre verificación de identidad ni sobre ceremonias de vinculación de autenticadores. DPoP no es ninguna de las dos cosas. Una prueba de que se usó una clave en el momento de la solicitud no es una ceremonia que haya establecido quién es una persona, así que no archives la prueba bajo esa ceremonia.

Tampoco trata de la inyección de aserciones. DPoP no es la frase «se aceptó una aserción, por lo tanto se ejecutó la decisión sobre el inquilino». Aceptar una prueba de posesión no significa que se haya ejecutado un punto de decisión de políticas del inquilino. Son eventos distintos.

Tampoco va de la caché de las API de identidad. Un objeto de directorio en caché no es esta prueba, y esta prueba no es una caché. La frescura de una fila del directorio y la posesión de una clave responden a preguntas diferentes. Un acierto de caché no demuestra que se usara una clave. Una prueba no actualiza un directorio.

No es «había un claim de contexto de autenticación». Los claims que describen cómo se autenticó alguien no son un derecho de inquilino. La presencia de contexto no es la aprobación de un cliente.

Y no es «la audiencia del token coincide con la API». La restricción de audiencia es un control diferente. Una audiencia coincidente nombra a un destinatario previsto del token. No nombra al inquilino cliente del MSP. Una API dispuesta a aceptar el token puede estar sirviendo igualmente al cliente equivocado.

Lo que importa para el comprador es que hay tres registros separados. Un token de técnico del MSP, un token de socio y un derecho de inquilino cliente son tres registros. Restringir al remitente el token del técnico no crea el derecho del cliente, no enumera los usuarios del cliente y no sustituye la comprobación de autorización del producto sobre el objeto afectado. Un técnico con un token bien vinculado puede seguir estando fuera del cliente que está a punto de abrir. La vinculación hace que el token sea más difícil de reutilizar. No escribe la fila del derecho.

Este artículo no afirma que Auris, ni ningún otro producto de Altovar, emita tokens vinculados con DPoP ni valide pruebas DPoP. Un token de máquina vinculado a un solo inquilino tampoco es prueba de DPoP: la vinculación al inquilino indica a qué inquilino pertenece el token, no que se haya verificado una prueba ni que un punto de decisión del producto haya concedido un derecho de inquilino cliente.

La frase que hay que repetir: no equipares «se presentó una prueba DPoP» o «un token de máquina está vinculado al inquilino» con «este cliente del MSP tiene derecho».