Une preuve DPoP montre qu'une clé a été utilisée. Elle ne confère aucun droit à un locataire MSP

Une preuve DPoP montre qu'une clé a été utilisée. Elle ne confère aucun droit à un locataire MSP

La phrase qu'un MSP entend de la part du client après que quelqu'un a activé les « jetons contraints à l'expéditeur » est : « DPoP est activé, donc la frontière entre locataires (tenants) est appliquée. » La réponse courte est non. La RFC 9449, section 4, consultée le 4 octobre 2026, indique qu'une preuve DPoP démontre la possession d'une clé et ne constitue pas, à elle seule, un mécanisme d'authentification ou de contrôle d'accès. La même section précise qu'un JWT de preuve DPoP valide ne suffit pas, à lui seul, pour prendre des décisions de contrôle d'accès.

Le résumé de cette page a un rôle plus étroit. Il décrit la contrainte à l'expéditeur des jetons OAuth 2.0 au moyen d'une preuve de possession au niveau applicatif, ce qui permet de détecter le rejeu des jetons d'accès et des jetons d'actualisation. La détection du rejeu n'est pas un droit de locataire. Ce n'est pas une décision d'autorisation produit. Un contrôle qui remarque qu'un jeton est présenté une nouvelle fois reste un contrôle portant sur ce jeton, pas un registre des clients qu'un MSP est autorisé à toucher.

La suite de cet article explique ce que la preuve est autorisée à signifier, quelles distinctions voisines établissent le NIST SP 800-63-3 et l'OWASP Authorization Cheat Sheet, avec quelles questions proches il ne faut pas la confondre, et pourquoi un jeton lié à un locataire n'est toujours pas un droit. Il reste au niveau de la norme : vous ne trouverez ici ni exemple de preuve, ni clé, ni chaîne de jeton, ni construction d'en-tête.

La section 4 est le point qu'aucun lecteur ne devrait manquer ; le voici donc reformulé. Une preuve DPoP montre la possession d'une clé. À elle seule, elle n'est pas une authentification. À elle seule, elle n'est pas un mécanisme de contrôle d'accès. Un JWT de preuve valide ne suffit pas, à lui seul, pour une décision de contrôle d'accès. Lorsqu'une preuve est présentée avec un jeton d'accès lié à la clé, la RFC renvoie à la section 7.1 pour ce cas, et l'assurance supplémentaire est que le client qui présente le jeton détient la clé. Une assurance sur la présentation n'est toujours pas une carte des clients du MSP. Détenir la clé ne désigne pas un locataire, ne liste pas les utilisateurs de ce locataire et n'approuve aucune action sur un objet à l'intérieur du locataire.

Le résumé et l'introduction, pris ensemble, décrivent un mécanisme qui contraint à l'expéditeur les jetons d'accès et d'actualisation et qui prend en charge la détection du rejeu. L'introduction indique aussi que DPoP lui-même ne sert pas à authentifier le client, même s'il peut être utilisé quelle que soit la façon dont le client s'authentifie. Les clients publics sont un cas d'usage principal sur cette page. C'est l'inverse de « DPoP a connecté l'utilisateur ». Une preuve qui accompagne un jeton est une contrainte sur qui peut présenter le jeton. Ce n'est ni la connexion, ni l'annuaire.

La section 3, dans les grandes lignes : la preuve est un JWT signé envoyé avec la requête, et le serveur de ressources doit toujours juger le jeton valide à tous les autres égards. « Valide à tous les autres égards » est le rappel pour l'acheteur : la signature et la possession ne remplacent ni l'expiration, ni l'audience, ni la décision propre de l'application. Ce sont des contrôles distincts, et une preuve ne les absorbe pas.

La section 2 présente l'objectif comme une classe de défense. La liaison vise à limiter l'utilisation d'un jeton porteur divulgué par des parties qui ne détiennent pas la clé. Les jetons porteurs sont utilisables par quiconque les détient ; DPoP vise à contraindre l'expéditeur. La RFC indique aussi que DPoP ne remplace pas un transport sécurisé.

Deux limites tirées des considérations de sécurité de la RFC méritent d'être citées. Une preuve ne protège pas l'intégrité de la requête entière. Un nonce fourni par le serveur est un moyen facultatif, pour les serveurs, de limiter la durée pendant laquelle une preuve reste utilisable. Un MSP qui a besoin d'une conception de nonce doit l'obtenir d'une revue d'implémentation de sa propre pile.

Le NIST SP 800-63-3 est un texte voisin, qui sert ici de dictionnaire. La page SP 800-63-3, consultée le 4 octobre 2026, indique que l'authentification établit la confiance dans le fait que le demandeur possède un authentificateur lié à l'identifiant. L'authentification ne détermine ni les autorisations ni les privilèges d'accès ; c'est une décision distincte, hors du champ de ces lignes directrices. Les relying parties peuvent utiliser une identité authentifiée et des attributs, ainsi que d'autres facteurs, pour prendre des décisions d'autorisation. La relying party est l'arbitre final quant à savoir si une assertion répond à ses critères d'accès au système, quels que soient les niveaux d'assurance définis par ces lignes directrices. Cet article ne retient que cette distinction ; les niveaux d'assurance sont un autre sujet.

L'OWASP Authorization Cheat Sheet, consulté le 4 octobre 2026, définit l'autorisation comme la vérification qu'une action demandée est approuvée pour une entité donnée, et indique que l'autorisation est distincte de l'authentification. Il plaide pour le refus par défaut, le moindre privilège et une vérification à chaque requête. Il avertit que la vérification intégrée d'un framework peut être la mauvaise pour l'application. C'est la phrase sur le point de décision pour cet article : une preuve de protocole n'est pas l'approbation, par l'application, d'une action limitée à un locataire. Une bibliothèque qui accepte une preuve a fait le travail de la bibliothèque. L'application doit encore décider si cet appelant peut toucher cet objet.

Mettons les trois côte à côte pour un MSP. DPoP peut contraindre la clé autorisée à présenter un jeton. Le NIST dit que même une authentification réussie n'est pas l'autorisation. L'OWASP dit que la décision d'autorisation relève de l'application, avec refus par défaut, à chaque requête. Aucun des trois n'est un registre des droits d'un locataire client. Un droit de locataire est un enregistrement produit : quel client, quelle action, quel objet. Une preuve, un authentificateur et un principe tiré d'un cheat sheet peuvent éclairer la façon dont cet enregistrement est vérifié. Ils ne sont pas l'enregistrement.

Ceci n'est pas une FAQ sur la vérification d'identité ou sur les cérémonies de liaison d'authentificateur. DPoP n'est ni l'une ni l'autre. Une preuve qu'une clé a été utilisée au moment de la requête n'est pas une cérémonie qui a établi l'identité d'une personne ; ne classez donc pas la preuve sous cette cérémonie.

Il n'est pas non plus question d'injection d'assertions. DPoP n'est pas la phrase « une assertion a été acceptée, donc la décision sur le locataire a été prise ». Accepter une preuve de possession ne signifie pas qu'un point de décision de politique de locataire a été exécuté. Ce sont des événements différents.

Il ne s'agit pas davantage de mise en cache des API d'identité. Un objet d'annuaire en cache n'est pas cette preuve, et cette preuve n'est pas un cache. La fraîcheur d'une ligne d'annuaire et la possession d'une clé répondent à des questions différentes. Un succès de cache ne montre pas qu'une clé a été utilisée. Une preuve ne rafraîchit pas un annuaire.

Ce n'est pas « un claim de contexte d'authentification était présent ». Les claims qui décrivent la façon dont quelqu'un s'est authentifié ne sont pas un droit de locataire. La présence d'un contexte n'est pas l'approbation d'un client.

Et ce n'est pas « l'audience du jeton correspond à l'API ». La restriction d'audience est un contrôle différent. Une audience correspondante désigne un destinataire prévu du jeton. Elle ne désigne pas le locataire client du MSP. Une API prête à accepter le jeton peut tout de même servir le mauvais client.

Ce qui compte pour l'acheteur, c'est qu'il existe trois registres distincts. Un jeton de technicien MSP, un jeton de partenaire et un droit de locataire client sont trois enregistrements. Contraindre à l'expéditeur le jeton du technicien ne crée pas le droit du client, ne liste pas les utilisateurs du client et ne remplace pas la vérification d'autorisation du produit sur l'objet concerné. Un technicien dont le jeton est bien lié peut tout de même se trouver hors du périmètre du client qu'il s'apprête à ouvrir. La liaison rend le jeton plus difficile à rejouer. Elle n'écrit pas la ligne de droit.

Cet article n'affirme pas qu'Auris, ni aucun autre produit Altovar, émet des jetons liés par DPoP ou valide des preuves DPoP. Un jeton machine lié à un seul locataire n'est pas non plus une preuve de DPoP : la liaison au locataire indique à quel locataire appartient le jeton, pas qu'une preuve a été vérifiée ni qu'un point de décision du produit a accordé un droit de locataire client.

La phrase à retenir : ne confondez pas « une preuve DPoP a été présentée » ou « un jeton machine est lié au locataire » avec « ce client MSP a le droit ».