Een DPoP-proof laat zien dat een sleutel is gebruikt. Het geeft een MSP-tenant geen rechten

Een DPoP-proof laat zien dat een sleutel is gebruikt. Het geeft een MSP-tenant geen rechten

De zin die een MSP van de klant hoort nadat iemand “sender-constrained tokens” heeft ingeschakeld, is: “DPoP staat aan, dus de tenantgrens wordt afgedwongen.” Het korte antwoord is nee. RFC 9449, sectie 4, gelezen op 4 oktober 2026, zegt dat een DPoP-proof het bezit van een sleutel aantoont en op zichzelf geen authenticatie- of toegangscontrolemechanisme is. Dezelfde sectie zegt dat een geldige DPoP-proof-JWT op zichzelf niet volstaat om beslissingen over toegangscontrole te nemen.

De samenvatting op die pagina heeft een beperktere taak. Ze beschrijft hoe OAuth 2.0-tokens met een bezitsbewijs op applicatieniveau aan de afzender worden gebonden, waardoor replay van access tokens en refresh tokens kan worden gedetecteerd. Replaydetectie is geen tenantrecht. Het is geen autorisatiebeslissing van een product. Een controle die merkt dat een token opnieuw wordt aangeboden, blijft een controle over dat token, geen register van welke klanten een MSP mag aanraken.

De rest van dit stuk behandelt wat de proof mag betekenen, welke verwante onderscheidingen NIST SP 800-63-3 en de OWASP Authorization Cheat Sheet maken, met welke nabije vragen het niet verward moet worden en waarom een aan een tenant gebonden token nog steeds geen recht is. Het blijft op het niveau van de standaard: hier staan geen voorbeeldproofs, sleutels, tokenstrings of headerconstructies.

Sectie 4 is het punt dat geen lezer mag missen, dus hier nog eens in andere woorden. Een DPoP-proof toont het bezit van een sleutel aan. Op zichzelf is het geen authenticatie. Op zichzelf is het geen toegangscontrolemechanisme. Een geldige proof-JWT volstaat op zichzelf niet voor een beslissing over toegangscontrole. Wanneer een proof samen met een aan de sleutel gebonden access token wordt aangeboden, verwijst de RFC voor dat geval naar sectie 7.1, en de extra zekerheid is dat de client die het token aanbiedt de sleutel bezit. Zekerheid over het aanbieden is nog steeds geen kaart van de klanten van een MSP. Het bezit van de sleutel noemt geen tenant, somt de gebruikers van die tenant niet op en keurt geen actie goed op een object binnen de tenant.

De samenvatting en de inleiding beschrijven samen een mechanisme dat access tokens en refresh tokens aan de afzender bindt en replaydetectie ondersteunt. De inleiding zegt ook dat DPoP zelf niet wordt gebruikt voor clientauthenticatie, al kan het worden gebruikt ongeacht hoe de client zich authenticeert. Publieke clients zijn op die pagina een belangrijk gebruiksscenario. Dat is het tegenovergestelde van “DPoP heeft de gebruiker ingelogd”. Een proof die met een token meereist, is een beperking op wie het token kan aanbieden. Het is niet de login en niet de directory.

Sectie 3 op hoofdlijnen: de proof is een ondertekende JWT die met het verzoek wordt meegestuurd, en de resource server moet het token nog steeds in alle andere opzichten geldig bevinden. “In alle andere opzichten geldig” is de herinnering voor de koper: handtekening en bezit vervangen de vervaldatum, de audience en de eigen beslissing van de applicatie niet. Dat zijn aparte controles, en een proof neemt ze niet over.

Sectie 2 formuleert het doel als een klasse van verdediging. Binding moet het gebruik van een gelekt bearer token beperken door partijen die de sleutel niet bezitten. Bearer tokens zijn bruikbaar voor wie ze in handen heeft; DPoP moet de afzender beperken. De RFC zegt ook dat DPoP geen vervanging is voor beveiligd transport.

Twee grenzen uit de beveiligingsoverwegingen van de RFC zijn het noemen waard. Een proof beschermt de integriteit van het hele verzoek niet. Een door de server verstrekte nonce is een optionele manier voor servers om te beperken hoe lang een proof bruikbaar blijft. Een MSP die een noncedesign nodig heeft, moet dat halen uit een implementatiereview van de eigen stack.

NIST SP 800-63-3 is verwant en dient hier als woordenboek. De pagina over SP 800-63-3, gelezen op 4 oktober 2026, zegt dat authenticatie vertrouwen geeft dat de aanvrager een authenticator bezit die aan de credential is gebonden. Authenticatie bepaalt geen autorisaties of toegangsrechten; dat is een aparte beslissing, buiten het bereik van die richtlijnen. Relying parties mogen een geauthenticeerde identiteit en attributen, plus andere factoren, gebruiken om autorisatiebeslissingen te nemen. De relying party beslist uiteindelijk of een assertion voldoet aan haar criteria voor systeemtoegang, ongeacht de assuranceniveaus die die richtlijnen definiëren. Dit artikel gebruikt alleen dat onderscheid; assuranceniveaus zijn een ander onderwerp.

De OWASP Authorization Cheat Sheet, gelezen op 4 oktober 2026, definieert autorisatie als controleren of een gevraagde actie is goedgekeurd voor een specifieke entiteit, en zegt dat autorisatie iets anders is dan authenticatie. De cheat sheet pleit voor standaard weigeren, minimale rechten en een controle bij elk verzoek. Ze waarschuwt dat de ingebouwde controle van een framework voor de applicatie de verkeerde kan zijn. Dat is de zin over het beslispunt voor dit artikel: een protocolproof is niet de goedkeuring door de applicatie van een actie binnen een tenant. Een bibliotheek die een proof accepteert, heeft het werk van de bibliotheek gedaan. De applicatie moet nog steeds beslissen of deze aanroeper dit object mag aanraken.

Zet de drie voor een MSP naast elkaar. DPoP kan beperken welke sleutel een token mag aanbieden. NIST zegt dat zelfs een geslaagde authenticatie niet de autorisatie is. OWASP zegt dat de autorisatiebeslissing een zaak van de applicatie is, standaard weigeren, bij elk verzoek. Geen van de drie is een register van rechten van de klanttenant. Een tenantrecht is een productrecord: welke klant, welke actie, welk object. Een proof, een authenticator en een principe uit een cheat sheet kunnen bepalen hoe dat record wordt gecontroleerd. Ze zijn het record niet.

Dit is geen FAQ over identiteitsverificatie of ceremonies voor authenticatorbinding. DPoP is geen van beide. Een bewijs dat een sleutel op het moment van het verzoek is gebruikt, is geen ceremonie die heeft vastgesteld wie iemand is; archiveer de proof dus niet onder die ceremonie.

Het gaat ook niet over assertion injection. DPoP is niet de zin “er is een assertion geaccepteerd, dus de tenantbeslissing is uitgevoerd.” Het accepteren van een bezitsbewijs betekent niet dat een policy decision point voor de tenant is uitgevoerd. Dat zijn verschillende gebeurtenissen.

Evenmin gaat het over caching van identiteits-API's. Een gecachet directoryobject is niet deze proof, en deze proof is geen cache. De actualiteit van een directoryrij en het bezit van een sleutel beantwoorden verschillende vragen. Een cachehit laat niet zien dat een sleutel is gebruikt. Een proof ververst geen directory.

Het is niet “er was een claim over de authenticatiecontext aanwezig”. Claims die beschrijven hoe iemand zich heeft geauthenticeerd, zijn geen tenantrecht. De aanwezigheid van context is geen goedkeuring van een klant.

En het is niet “de audience van het token komt overeen met de API”. Audiencebeperking is een andere controle. Een overeenkomende audience noemt een beoogde ontvanger van het token. Ze noemt niet de klanttenant van de MSP. Een API die het token wil accepteren, kan nog steeds de verkeerde klant bedienen.

Wat voor de koper telt, is dat er drie aparte records zijn. Een token van een MSP-technicus, een partnertoken en een recht van een klanttenant zijn drie records. Het token van de technicus aan de afzender binden creëert het recht van de klant niet, somt de gebruikers van de klant niet op en vervangt niet de autorisatiecontrole van het product op het object dat wordt aangeraakt. Een technicus met een goed gebonden token kan nog steeds buiten de klant staan die hij op het punt staat te openen. De binding maakt replay van het token moeilijker. Ze schrijft de rij met het recht niet.

Dit artikel beweert niet dat Auris, of een ander product van Altovar, met DPoP gebonden tokens uitgeeft of DPoP-proofs valideert. Ook een machinetoken dat aan één tenant is gebonden, is geen bewijs van DPoP: de tenantbinding zegt bij welke tenant het token hoort, niet dat er een proof is gecontroleerd of dat een beslispunt in het product een recht voor een klanttenant heeft toegekend.

De zin om te onthouden: stel “er is een DPoP-proof aangeboden” of “een machinetoken is aan de tenant gebonden” niet gelijk aan “deze MSP-klant heeft het recht”.