Uma prova DPoP mostra que uma chave foi usada. Não dá direito a um tenant de MSP

Uma prova DPoP mostra que uma chave foi usada. Não dá direito a um tenant de MSP

A frase que um MSP ouve do cliente depois de alguém ativar os «tokens restritos ao remetente» é: «o DPoP está ativado, por isso a fronteira do tenant está a ser aplicada.» A resposta curta é não. O RFC 9449, secção 4, lido a 4 de outubro de 2026, diz que uma prova DPoP demonstra a posse de uma chave e que, por si só, não é um mecanismo de autenticação nem de controlo de acesso. A mesma secção diz que um JWT de prova DPoP válido não basta, por si só, para tomar decisões de controlo de acesso.

O resumo dessa página tem uma função mais restrita. Descreve a restrição ao remetente dos tokens OAuth 2.0 através de uma prova de posse ao nível da aplicação, o que permite detetar a reutilização (replay) de access tokens e refresh tokens. Detetar a reutilização não é um direito de tenant. Não é uma decisão de autorização do produto. Um controlo que repara que um token está a ser apresentado de novo continua a ser um controlo sobre esse token, e não um registo dos clientes em que um MSP pode tocar.

O resto deste artigo explica o que a prova pode significar, que distinções afins estabelecem o NIST SP 800-63-3 e a OWASP Authorization Cheat Sheet, com que questões próximas não deve ser confundida e porque é que um token associado a um tenant continua a não ser um direito. O texto fica ao nível da norma: aqui não há provas de exemplo, chaves, cadeias de tokens nem construção de cabeçalhos.

A secção 4 é o ponto que nenhum leitor deve perder, por isso aqui fica de novo, por outras palavras. Uma prova DPoP mostra a posse de uma chave. Por si só, não é autenticação. Por si só, não é um mecanismo de controlo de acesso. Um JWT de prova válido não basta, por si só, para uma decisão de controlo de acesso. Quando uma prova é apresentada juntamente com um access token associado à chave, o RFC remete para a secção 7.1 nesse caso, e a garantia adicional é que o cliente que apresenta o token detém a chave. Uma garantia sobre a apresentação continua a não ser um mapa dos clientes do MSP. Deter a chave não identifica um tenant, não lista os utilizadores desse tenant e não aprova uma ação sobre um objeto dentro do tenant.

O resumo e a introdução, em conjunto, descrevem um mecanismo que restringe ao remetente os access tokens e os refresh tokens e que suporta a deteção de reutilização. A introdução diz também que o DPoP, em si, não é usado para autenticar o cliente, embora possa ser usado independentemente da forma como o cliente se autentica. Os clientes públicos são um dos principais casos de utilização indicados nessa página. É o oposto de «o DPoP iniciou a sessão do utilizador». Uma prova que viaja com um token é uma restrição sobre quem pode apresentar o token. Não é o início de sessão nem o diretório.

A secção 3, em linhas gerais: a prova é um JWT assinado enviado com o pedido, e o servidor de recursos continua a ter de considerar o token válido em todos os outros aspetos. «Válido em todos os outros aspetos» é o lembrete para o comprador: a assinatura e a posse não substituem a validade temporal, a audiência nem a decisão própria da aplicação. São controlos separados, e uma prova não os absorve.

A secção 2 apresenta o objetivo como uma classe de defesa. A associação destina-se a limitar a utilização de um bearer token divulgado por partes que não detêm a chave. Os bearer tokens podem ser usados por quem os tiver; o DPoP destina-se a restringir o remetente. O RFC diz também que o DPoP não substitui um transporte seguro.

Vale a pena referir dois limites das considerações de segurança do RFC. Uma prova não protege a integridade de todo o pedido. Um nonce fornecido pelo servidor é uma forma opcional de os servidores limitarem durante quanto tempo uma prova continua utilizável. Um MSP que precise de um desenho de nonce deve obtê-lo numa revisão da implementação da sua própria stack.

O NIST SP 800-63-3 é um texto afim e serve aqui de dicionário. A página do SP 800-63-3, lida a 4 de outubro de 2026, diz que a autenticação estabelece a confiança de que o requerente possui um autenticador associado à credencial. A autenticação não determina autorizações nem privilégios de acesso; essa é uma decisão separada, fora do âmbito dessas diretrizes. As relying parties podem usar uma identidade autenticada e atributos, além de outros fatores, para tomar decisões de autorização. A relying party é o árbitro final quanto a saber se uma asserção cumpre os seus critérios de acesso ao sistema, independentemente dos níveis de garantia definidos por essas diretrizes. Este artigo usa apenas essa distinção; os níveis de garantia são outro tema.

A OWASP Authorization Cheat Sheet, lida a 4 de outubro de 2026, define a autorização como a verificação de que uma ação pedida está aprovada para uma entidade específica, e diz que a autorização é distinta da autenticação. Defende a recusa por omissão, o privilégio mínimo e uma verificação em cada pedido. Avisa que a verificação integrada de uma framework pode ser a verificação errada para a aplicação. É essa a frase sobre o ponto de decisão neste artigo: uma prova de protocolo não é a aprovação, pela aplicação, de uma ação no âmbito de um tenant. Uma biblioteca que aceita uma prova fez o trabalho da biblioteca. A aplicação continua a ter de decidir se este chamador pode tocar neste objeto.

Coloquemos os três lado a lado para um MSP. O DPoP pode restringir que chave pode apresentar um token. O NIST diz que nem mesmo uma autenticação bem-sucedida é a autorização. A OWASP diz que a decisão de autorização cabe à aplicação, com recusa por omissão, em cada pedido. Nenhum dos três é um registo de direitos do tenant do cliente. Um direito de tenant é um registo do produto: que cliente, que ação, que objeto. Uma prova, um autenticador e um princípio de uma cheat sheet podem orientar a forma como esse registo é verificado. Não são o registo.

Esta não é uma FAQ sobre verificação de identidade nem sobre cerimónias de associação de autenticadores. O DPoP não é nenhuma das duas coisas. Uma prova de que uma chave foi usada no momento do pedido não é uma cerimónia que tenha estabelecido quem é uma pessoa, por isso não arquive a prova nessa categoria.

Também não trata de injeção de asserções. O DPoP não é a frase «uma asserção foi aceite, logo a decisão sobre o tenant foi executada». Aceitar uma prova de posse não significa que um ponto de decisão de políticas do tenant tenha sido executado. São eventos diferentes.

Nem trata da cache das APIs de identidade. Um objeto de diretório em cache não é esta prova, e esta prova não é uma cache. A atualidade de uma linha do diretório e a posse de uma chave respondem a perguntas diferentes. Um acerto na cache não mostra que uma chave foi usada. Uma prova não atualiza um diretório.

Não é «estava presente um claim de contexto de autenticação». Os claims que descrevem como alguém se autenticou não são um direito de tenant. A presença de contexto não é a aprovação de um cliente.

E não é «a audiência do token corresponde à API». A restrição de audiência é um controlo diferente. Uma audiência correspondente identifica um destinatário previsto do token. Não identifica o tenant do cliente do MSP. Uma API disposta a aceitar o token pode mesmo assim estar a servir o cliente errado.

O que importa para o comprador é que há três registos separados. Um token de técnico do MSP, um token de parceiro e um direito de tenant do cliente são três registos. Restringir ao remetente o token do técnico não cria o direito do cliente, não lista os utilizadores do cliente e não substitui a verificação de autorização do produto sobre o objeto em causa. Um técnico com um token bem associado pode, ainda assim, estar fora do cliente que se prepara para abrir. A associação torna o token mais difícil de reutilizar. Não escreve a linha do direito.

Este artigo não afirma que o Auris, ou qualquer outro produto Altovar, emita tokens associados por DPoP ou valide provas DPoP. Um token de máquina associado a um único tenant também não é prova de DPoP: a associação ao tenant indica a que tenant o token pertence, e não que uma prova foi verificada nem que um ponto de decisão do produto concedeu um direito de tenant do cliente.

A frase a repetir: não equipare «foi apresentada uma prova DPoP» ou «um token de máquina está associado ao tenant» a «este cliente do MSP tem direito».