O dovadă DPoP arată că o cheie a fost folosită. Nu conferă drepturi unui tenant MSP

O dovadă DPoP arată că o cheie a fost folosită. Nu conferă drepturi unui tenant MSP

Fraza pe care un MSP o aude de la client după ce cineva activează „token-urile restricționate la expeditor” (sender-constrained tokens) este: „DPoP este activat, deci granița dintre tenanturi este impusă.” Răspunsul scurt este nu. RFC 9449, secțiunea 4, citit pe 4 octombrie 2026, spune că o dovadă DPoP demonstrează deținerea unei chei și, în sine, nu este un mecanism de autentificare sau de control al accesului. Aceeași secțiune spune că un JWT de dovadă DPoP valid nu este suficient, singur, pentru a lua decizii de control al accesului.

Rezumatul de pe acea pagină are un rol mai restrâns. Descrie restricționarea la expeditor a token-urilor OAuth 2.0 printr-o dovadă de deținere la nivel de aplicație, ceea ce permite detectarea reutilizării (replay) token-urilor de acces și a token-urilor de reîmprospătare. Detectarea reutilizării nu este un drept al tenantului. Nu este o decizie de autorizare a produsului. Un control care observă că un token este prezentat din nou rămâne un control asupra acelui token, nu un registru al clienților pe care un MSP are voie să îi atingă.

Restul articolului explică ce are voie să însemne dovada, ce distincții înrudite fac NIST SP 800-63-3 și OWASP Authorization Cheat Sheet, cu ce întrebări apropiate nu trebuie confundată și de ce un token legat de un tenant tot nu este un drept. Textul rămâne la nivelul standardului: aici nu există dovezi de exemplu, chei, șiruri de token-uri sau construcții de antete.

Secțiunea 4 este punctul pe care niciun cititor nu ar trebui să îl rateze, așa că iată-l din nou, cu alte cuvinte. O dovadă DPoP arată deținerea unei chei. În sine, nu este autentificare. În sine, nu este un mecanism de control al accesului. Un JWT de dovadă valid nu este suficient, singur, pentru o decizie de control al accesului. Când o dovadă este prezentată împreună cu un token de acces legat de cheie, RFC-ul trimite pentru acest caz la secțiunea 7.1, iar garanția suplimentară este că clientul care prezintă token-ul deține cheia. O garanție privind prezentarea nu este totuși o hartă a clienților MSP. Deținerea cheii nu numește un tenant, nu listează utilizatorii acelui tenant și nu aprobă o acțiune asupra unui obiect din interiorul tenantului.

Rezumatul și introducerea, luate împreună, descriu un mecanism care restricționează la expeditor token-urile de acces și token-urile de reîmprospătare și care sprijină detectarea reutilizării. Introducerea spune și că DPoP în sine nu este folosit pentru autentificarea clientului, deși poate fi folosit indiferent de modul în care se autentifică clientul. Clienții publici sunt unul dintre principalele cazuri de utilizare de pe acea pagină. Este opusul afirmației „DPoP l-a autentificat pe utilizator”. O dovadă care călătorește împreună cu un token este o restricție privind cine poate prezenta token-ul. Nu este autentificarea și nu este directorul.

Secțiunea 3, în linii mari: dovada este un JWT semnat trimis odată cu cererea, iar serverul de resurse trebuie în continuare să considere token-ul valid din toate celelalte puncte de vedere. „Valid din toate celelalte puncte de vedere” este reamintirea pentru cumpărător: semnătura și deținerea nu înlocuiesc expirarea, audiența sau decizia proprie a aplicației. Acestea sunt controale separate, iar o dovadă nu le preia.

Secțiunea 2 formulează obiectivul ca pe o clasă de apărare. Legarea are scopul de a limita folosirea unui bearer token scurs de către părți care nu dețin cheia. Bearer token-urile pot fi folosite de oricine le are; DPoP are scopul de a restricționa expeditorul. RFC-ul spune și că DPoP nu înlocuiește un transport securizat.

Merită numite două limite din considerațiile de securitate ale RFC-ului. O dovadă nu protejează integritatea întregii cereri. Un nonce furnizat de server este o modalitate opțională prin care serverele pot limita cât timp rămâne utilizabilă o dovadă. Un MSP care are nevoie de un design pentru nonce ar trebui să îl obțină dintr-o revizuire a implementării propriei stive.

NIST SP 800-63-3 este un text înrudit și servește aici drept dicționar. Pagina SP 800-63-3, citită pe 4 octombrie 2026, spune că autentificarea stabilește încrederea că solicitantul deține un autentificator legat de credențial. Autentificarea nu determină autorizări sau privilegii de acces; aceasta este o decizie separată, în afara domeniului acestor ghiduri. Părțile care se bazează pe autentificare (relying parties) pot folosi o identitate autentificată și atribute, plus alți factori, pentru a lua decizii de autorizare. Partea care se bazează pe autentificare este arbitrul final în privința faptului că o aserțiune îndeplinește criteriile sale de acces la sistem, indiferent de nivelurile de asigurare definite de aceste ghiduri. Acest articol folosește doar această distincție; nivelurile de asigurare sunt un subiect separat.

OWASP Authorization Cheat Sheet, citit pe 4 octombrie 2026, definește autorizarea ca verificarea faptului că o acțiune solicitată este aprobată pentru o anumită entitate și spune că autorizarea este distinctă de autentificare. Pledează pentru refuzul implicit, privilegiul minim și o verificare la fiecare cerere. Avertizează că verificarea integrată a unui framework poate fi verificarea greșită pentru aplicație. Aceasta este fraza despre punctul de decizie pentru acest articol: o dovadă de protocol nu este aprobarea, de către aplicație, a unei acțiuni limitate la un tenant. O bibliotecă ce acceptă o dovadă și-a făcut treaba de bibliotecă. Aplicația trebuie în continuare să decidă dacă acest apelant poate atinge acest obiect.

Să le punem pe cele trei una lângă alta, din perspectiva unui MSP. DPoP poate restricționa ce cheie poate prezenta un token. NIST spune că nici măcar o autentificare reușită nu este autorizarea. OWASP spune că decizia de autorizare ține de aplicație, cu refuz implicit, la fiecare cerere. Niciuna dintre cele trei nu este un registru al drepturilor tenantului client. Un drept de tenant este o înregistrare în produs: ce client, ce acțiune, ce obiect. O dovadă, un autentificator și un principiu dintr-un cheat sheet pot influența modul în care este verificată această înregistrare. Nu sunt înregistrarea.

Acesta nu este un FAQ despre verificarea identității sau despre ceremoniile de legare a autentificatorului. DPoP nu este nici una, nici alta. O dovadă că o cheie a fost folosită în momentul cererii nu este o ceremonie care a stabilit cine este o persoană, așa că nu clasa dovada în categoria acelei ceremonii.

Nu este vorba nici despre injectarea de aserțiuni. DPoP nu este fraza „o aserțiune a fost acceptată, deci decizia privind tenantul a rulat”. Acceptarea unei dovezi de deținere nu înseamnă că s-a executat un punct de decizie al politicilor de tenant. Sunt evenimente diferite.

Nu este vorba nici despre cache-ul API-urilor de identitate. Un obiect de director aflat în cache nu este această dovadă, iar această dovadă nu este un cache. Prospețimea unui rând din director și deținerea unei chei răspund la întrebări diferite. O potrivire în cache nu arată că a fost folosită o cheie. O dovadă nu reîmprospătează un director.

Nu este „exista un claim de context de autentificare”. Claim-urile care descriu cum s-a autentificat cineva nu sunt un drept de tenant. Prezența contextului nu înseamnă aprobarea unui client.

Și nu este „audiența token-ului corespunde API-ului”. Restricționarea audienței este un control diferit. O audiență corespunzătoare numește un destinatar prevăzut al token-ului. Nu numește tenantul clientului MSP. Un API dispus să accepte token-ul poate totuși să deservească clientul greșit.

Pentru cumpărător contează că există trei înregistrări separate. Un token de tehnician MSP, un token de partener și un drept de tenant client sunt trei înregistrări. Restricționarea la expeditor a token-ului tehnicianului nu creează dreptul clientului, nu listează utilizatorii clientului și nu înlocuiește verificarea de autorizare a produsului asupra obiectului vizat. Un tehnician cu un token bine legat poate fi totuși în afara clientului pe care urmează să îl deschidă. Legarea face token-ul mai greu de reutilizat. Nu scrie rândul dreptului.

Acest articol nu afirmă că Auris sau vreun alt produs Altovar emite token-uri legate prin DPoP sau validează dovezi DPoP. Nici un token de mașină legat de un singur tenant nu este o dovadă de DPoP: legarea de tenant arată cărui tenant îi aparține token-ul, nu că a fost verificată o dovadă sau că un punct de decizie din produs a acordat un drept de tenant client.

Fraza de repetat: nu echivala „a fost prezentată o dovadă DPoP” sau „un token de mașină este legat de tenant” cu „acest client MSP are drept”.