Ein DPoP-Proof zeigt, dass ein Schlüssel verwendet wurde. Er berechtigt keinen MSP-Tenant

Ein DPoP-Proof zeigt, dass ein Schlüssel verwendet wurde. Er berechtigt keinen MSP-Tenant

Der Satz, den ein MSP vom Kunden hört, nachdem jemand „sender-constrained tokens“ aktiviert hat, lautet: „DPoP ist aktiv, also wird die Tenant-Grenze durchgesetzt.“ Die kurze Antwort lautet: nein. RFC 9449, Abschnitt 4, gelesen am 4. Oktober 2026, sagt, dass ein DPoP-Proof den Besitz eines Schlüssels nachweist und für sich genommen kein Authentifizierungs- oder Zugriffskontrollmechanismus ist. Derselbe Abschnitt sagt, dass ein gültiges DPoP-Proof-JWT allein nicht ausreicht, um Zugriffskontrollentscheidungen zu treffen.

Das Abstract auf dieser Seite hat eine engere Aufgabe. Es beschreibt, wie OAuth-2.0-Tokens mit einem Besitznachweis auf Anwendungsebene an den Absender gebunden werden, wodurch sich Replay von Access Tokens und Refresh Tokens erkennen lässt. Replay-Erkennung ist keine Tenant-Berechtigung. Sie ist keine Autorisierungsentscheidung eines Produkts. Eine Kontrolle, die bemerkt, dass ein Token erneut vorgelegt wird, ist immer noch eine Kontrolle über dieses Token, kein Verzeichnis darüber, welche Kunden ein MSP anfassen darf.

Der Rest dieses Beitrags behandelt, was der Proof bedeuten darf, welche benachbarten Unterscheidungen NIST SP 800-63-3 und das OWASP Authorization Cheat Sheet treffen, mit welchen benachbarten Fragen er nicht verwechselt werden sollte und warum ein an den Tenant gebundenes Token trotzdem keine Berechtigung ist. Er bleibt auf der Ebene des Standards: Es gibt hier keine Beispiel-Proofs, Schlüssel, Token-Strings oder Header-Konstruktionen.

Abschnitt 4 ist der Punkt, den niemand überlesen sollte, deshalb hier noch einmal mit anderen Worten. Ein DPoP-Proof zeigt den Besitz eines Schlüssels. Für sich genommen ist er keine Authentifizierung. Für sich genommen ist er kein Zugriffskontrollmechanismus. Ein gültiges Proof-JWT reicht allein nicht für eine Zugriffskontrollentscheidung. Wird ein Proof zusammen mit einem schlüsselgebundenen Access Token vorgelegt, verweist der RFC für diesen Fall auf Abschnitt 7.1, und die zusätzliche Zusicherung besteht darin, dass der Client, der das Token vorlegt, den Schlüssel besitzt. Eine Zusicherung über die Vorlage ist trotzdem keine Landkarte der MSP-Kunden. Den Schlüssel zu besitzen benennt keinen Tenant, listet nicht die Benutzer dieses Tenants auf und genehmigt keine Aktion auf einem Objekt innerhalb des Tenants.

Abstract und Einleitung beschreiben zusammen einen Mechanismus, der Access Tokens und Refresh Tokens an den Absender bindet und Replay-Erkennung unterstützt. Die Einleitung sagt außerdem, dass DPoP selbst nicht zur Client-Authentifizierung dient, auch wenn es unabhängig davon eingesetzt werden kann, wie sich der Client authentifiziert. Öffentliche Clients sind auf dieser Seite ein zentraler Anwendungsfall. Das ist das Gegenteil von „DPoP hat den Benutzer angemeldet“. Ein Proof, der mit einem Token mitreist, ist eine Einschränkung dafür, wer das Token vorlegen kann. Er ist nicht die Anmeldung und nicht das Verzeichnis.

Abschnitt 3 im Überblick: Der Proof ist ein signiertes JWT, das mit der Anfrage gesendet wird, und der Resource Server muss das Token trotzdem in jeder anderen Hinsicht als gültig befinden. „In jeder anderen Hinsicht gültig“ ist die Erinnerung für den Käufer: Signatur und Besitz ersetzen weder das Ablaufdatum noch die Audience noch die eigene Entscheidung der Anwendung. Das sind getrennte Kontrollen, und ein Proof macht sie nicht überflüssig.

Abschnitt 2 beschreibt das Ziel als Klasse von Abwehrmaßnahmen. Die Bindung soll die Nutzung eines abgeflossenen Bearer Tokens durch Parteien begrenzen, die den Schlüssel nicht besitzen. Bearer Tokens kann nutzen, wer sie hat; DPoP soll den Absender einschränken. Der RFC sagt außerdem, dass DPoP kein Ersatz für einen sicheren Transport ist.

Zwei Grenzen aus den Sicherheitsbetrachtungen des RFC sind erwähnenswert. Ein Proof schützt nicht die Integrität der gesamten Anfrage. Eine vom Server gelieferte Nonce ist eine optionale Möglichkeit für Server, zu begrenzen, wie lange ein Proof verwendbar bleibt. Ein MSP, der ein Nonce-Design braucht, sollte es aus einem Implementierungs-Review seines eigenen Stacks ableiten.

NIST SP 800-63-3 ist benachbart und dient hier als Wörterbuch. Die Seite zu SP 800-63-3, gelesen am 4. Oktober 2026, sagt, dass Authentifizierung das Vertrauen herstellt, dass der Antragsteller einen an die Anmeldeinformation gebundenen Authenticator besitzt. Authentifizierung bestimmt keine Autorisierungen oder Zugriffsrechte; das ist eine separate Entscheidung außerhalb des Geltungsbereichs dieser Richtlinien. Relying Parties können eine authentifizierte Identität und Attribute sowie weitere Faktoren nutzen, um Autorisierungsentscheidungen zu treffen. Die Relying Party entscheidet letztlich, ob eine Assertion ihre Kriterien für den Systemzugang erfüllt, unabhängig von den Assurance-Levels, die diese Richtlinien definieren. Dieser Artikel nutzt nur diese Unterscheidung; Assurance-Levels sind ein eigenes Thema.

Das OWASP Authorization Cheat Sheet, gelesen am 4. Oktober 2026, definiert Autorisierung als Prüfung, ob eine angeforderte Aktion für eine bestimmte Entität genehmigt ist, und sagt, dass Autorisierung von Authentifizierung zu unterscheiden ist. Es plädiert für Deny by Default, Least Privilege und eine Prüfung bei jeder Anfrage. Es warnt, dass die eingebaute Prüfung eines Frameworks für die Anwendung die falsche sein kann. Das ist der Satz zum Entscheidungspunkt für diesen Artikel: Ein Protokoll-Proof ist nicht die Genehmigung einer tenantbezogenen Aktion durch die Anwendung. Eine Bibliothek, die einen Proof akzeptiert, hat die Arbeit der Bibliothek getan. Die Anwendung muss trotzdem entscheiden, ob dieser Aufrufer dieses Objekt anfassen darf.

Stellen wir die drei für einen MSP nebeneinander. DPoP kann einschränken, welcher Schlüssel ein Token vorlegen darf. NIST sagt, dass selbst eine erfolgreiche Authentifizierung nicht die Autorisierung ist. OWASP sagt, dass die Autorisierungsentscheidung Sache der Anwendung ist, mit Deny by Default, bei jeder Anfrage. Keines der drei ist ein Berechtigungsdatensatz für einen Kunden-Tenant. Eine Tenant-Berechtigung ist ein Produktdatensatz: welcher Kunde, welche Aktion, welches Objekt. Ein Proof, ein Authenticator und ein Grundsatz aus einem Cheat Sheet können beeinflussen, wie dieser Datensatz geprüft wird. Sie sind nicht der Datensatz.

Dies ist keine FAQ über Identity Proofing oder Zeremonien zur Authenticator-Bindung. DPoP ist weder das eine noch das andere. Ein Nachweis, dass ein Schlüssel zum Zeitpunkt der Anfrage verwendet wurde, ist keine Zeremonie, die festgestellt hat, wer eine Person ist; legen Sie den Proof also nicht unter dieser Zeremonie ab.

Es geht auch nicht um Assertion Injection. DPoP ist nicht der Satz „Eine Assertion wurde akzeptiert, also ist die Tenant-Entscheidung gelaufen.“ Einen Besitznachweis zu akzeptieren bedeutet nicht, dass ein Policy Decision Point für den Tenant ausgeführt wurde. Das sind verschiedene Ereignisse.

Ebenso wenig geht es um das Caching von Identity-APIs. Ein zwischengespeichertes Verzeichnisobjekt ist nicht dieser Proof, und dieser Proof ist kein Cache. Die Aktualität einer Verzeichniszeile und der Besitz eines Schlüssels beantworten verschiedene Fragen. Ein Cache-Treffer zeigt nicht, dass ein Schlüssel verwendet wurde. Ein Proof aktualisiert kein Verzeichnis.

Es ist nicht „ein Authentication-Context-Claim war vorhanden“. Claims, die beschreiben, wie sich jemand authentifiziert hat, sind keine Tenant-Berechtigung. Das Vorhandensein von Kontext ist keine Genehmigung für einen Kunden.

Und es ist nicht „die Audience des Tokens passt zur API“. Audience-Beschränkung ist eine andere Kontrolle. Eine passende Audience benennt einen vorgesehenen Empfänger des Tokens. Sie benennt nicht den Kunden-Tenant des MSP. Eine API, die das Token anzunehmen bereit ist, kann trotzdem den falschen Kunden bedienen.

Für den Käufer zählt, dass es drei getrennte Datensätze gibt. Ein Token eines MSP-Technikers, ein Partner-Token und eine Kunden-Tenant-Berechtigung sind drei Datensätze. Das Token des Technikers an den Absender zu binden, erzeugt nicht die Berechtigung für den Kunden, listet nicht die Benutzer des Kunden auf und ersetzt nicht die Autorisierungsprüfung des Produkts für das betroffene Objekt. Ein Techniker mit gut gebundenem Token kann trotzdem außerhalb des Kunden stehen, den er gleich öffnen will. Die Bindung erschwert das Replay des Tokens. Sie schreibt nicht die Berechtigungszeile.

Dieser Artikel behauptet nicht, dass Auris oder ein anderes Altovar-Produkt DPoP-gebundene Tokens ausstellt oder DPoP-Proofs prüft. Auch ein Maschinen-Token, das an einen einzelnen Tenant gebunden ist, ist kein Beleg für DPoP: Die Tenant-Bindung sagt, zu welchem Tenant das Token gehört, nicht, dass ein Proof geprüft wurde oder dass ein Entscheidungspunkt im Produkt eine Kunden-Tenant-Berechtigung erteilt hat.

Der Satz zum Wiederholen: Setzen Sie „ein DPoP-Proof wurde vorgelegt“ oder „ein Maschinen-Token ist an den Tenant gebunden“ nicht mit „dieser MSP-Kunde ist berechtigt“ gleich.