A DPoP proof shows a key was used. It does not entitle an MSP tenant

A DPoP proof shows a key was used. It does not entitle an MSP tenant

The buyer sentence an MSP hears after someone enables “sender-constrained tokens” is: “DPoP is on, so the tenant boundary is enforced.” The short answer is no. RFC 9449, section 4, read on 4 October 2026, says a DPoP proof demonstrates possession of a key and, by itself, is not an authentication or access-control mechanism. The same section says a valid DPoP proof JWT is not sufficient alone to make access-control decisions.

The abstract on that page has a narrower job. It describes sender-constraining OAuth 2.0 tokens with an application-level proof of possession, which allows replay of access tokens and refresh tokens to be detected. Replay detection is not a tenant entitlement. It is not a product authorization decision. A control that notices a token being presented again is still a control about that token, not a record of which customer an MSP is allowed to touch.

The rest of this piece covers what the proof is allowed to mean, the adjacent distinctions drawn by NIST SP 800-63-3 and the OWASP Authorization Cheat Sheet, which neighbouring questions it should not be confused with, and why a tenant-bound token is still not an entitlement. It stays at the level of the standard: there are no example proofs, keys, token strings or header construction here.

Section 4 is the point a reader should not miss, so here it is again in other words. A DPoP proof shows possession of a key. By itself it is not authentication. By itself it is not an access-control mechanism. A valid proof JWT is not sufficient alone for an access-control decision. When a proof is presented together with a key-bound access token, the RFC points to section 7.1 for that case, and the assurance it adds is that the client presenting the token holds the key. Assurance about presentation is still not a map of MSP customers. Holding the key does not name a tenant, does not list that tenant’s users, and does not approve an action on an object inside the tenant.

The abstract and the introduction, taken together, describe a mechanism that sender-constrains access tokens and refresh tokens and that supports replay detection. The introduction also says DPoP itself is not used for client authentication, even though it can be used regardless of how the client authenticates. Public clients are a primary use case on that page. That is the opposite of “DPoP logged the user in.” A proof that travels with a token is a constraint on who can present the token. It is not the login, and it is not the directory.

Section 3, at a high level: the proof is a signed JWT carried with the request, and the resource server still has to find the token valid in all other respects. “Valid in all other respects” is the buyer’s reminder: signature and possession do not replace expiry, audience, or the application’s own decision. Those are separate controls, and a proof does not absorb them.

Section 2 states the objective as a class of defense. Binding is meant to limit use of a leaked bearer token by parties who do not hold the key. Bearer tokens are usable by whoever holds them; DPoP is meant to constrain the sender. The RFC also says DPoP is not a substitute for a secure transport.

Two limits from the RFC’s security considerations are worth naming. A proof does not protect the integrity of the whole request. A server-supplied nonce is one optional way for servers to limit how long a proof stays usable. An MSP that needs a nonce design should get it from an implementation review of its own stack.

NIST SP 800-63-3 is adjacent, and here it serves as a dictionary. The SP 800-63-3 page, read on 4 October 2026, says authentication establishes confidence that the claimant possesses an authenticator bound to the credential. Authentication does not determine authorizations or access privileges; that is a separate decision, outside the scope of those guidelines. Relying parties may use an authenticated identity and attributes, plus other factors, to make authorization decisions. The relying party is the final arbiter of whether an assertion meets its criteria for system access, regardless of the assurance levels those guidelines define. This article uses only that distinction; assurance levels are a separate topic.

The OWASP Authorization Cheat Sheet, read on 4 October 2026, defines authorization as verifying that a requested action is approved for a specific entity, and it says authorization is distinct from authentication. It argues for deny by default, least privilege, and a check on every request. It warns that a framework’s built-in check can be the wrong check for the application. That is the decision-point sentence for this article: a protocol proof is not the application’s approval of a tenant-scoped action. A library that accepts a proof has done the library’s job. The application still has to decide whether this caller may touch this object.

Put the three side by side for an MSP. DPoP can constrain which key may present a token. NIST says even a successful authentication is not the authorization. OWASP says the authorization decision is an application concern, deny by default, on every request. None of the three is a customer-tenant entitlement record. A tenant entitlement is a product record: which customer, which action, which object. A proof, an authenticator, and a cheat-sheet principle can inform how that record is checked. They are not the record.

This is not a FAQ about identity proofing or authenticator binding ceremonies. DPoP is neither of those. A proof that a key was used at request time is not a ceremony that established who a person is, so do not file the proof under that ceremony.

Nor is it about assertion injection. DPoP is not the sentence “an assertion was accepted, therefore the tenant decision ran.” Accepting a proof of possession does not mean a tenant policy decision point executed. Those are different events.

It is not about identity-API caching either. A cached directory object is not this proof, and this proof is not a cache. Freshness of a directory row and possession of a key answer different questions. A cache hit does not show that a key was used. A proof does not refresh a directory.

It is not “an authentication-context claim was present.” Claims that describe how someone authenticated are not a tenant entitlement. Presence of context is not approval of a customer.

And it is not “the token’s audience matches the API.” Audience restriction is a different control. A matching audience names an intended recipient of the token. It does not name the MSP’s customer tenant. An API that is willing to accept the token can still be serving the wrong customer.

What matters for the buyer is that there are three separate records. An MSP technician token, a partner token, and a customer-tenant entitlement are three records. Sender-constraining the technician token does not create the customer entitlement, does not list the customer’s users, and does not replace the product’s authorization check on the object being touched. A well-bound technician can still be outside the customer they are about to open. The binding makes the token harder to replay. It does not write the entitlement row.

This article does not claim that Auris, or any other Altovar product, issues DPoP-bound tokens or validates DPoP proofs. A machine token that is bound to a single tenant is not evidence of DPoP either: the tenant binding says which tenant the token belongs to, not that a proof was checked or that a product decision point granted a customer-tenant entitlement.

The line to repeat: do not equate “a DPoP proof was presented” or “a machine token is tenant-bound” with “this MSP customer is entitled.”