Dowód DPoP pokazuje, że użyto klucza. Nie uprawnia on dzierżawy MSP

Dowód DPoP pokazuje, że użyto klucza. Nie uprawnia on dzierżawy MSP

Zdanie, które MSP słyszy od klienta po tym, jak ktoś włączy „tokeny ograniczone do nadawcy” (sender-constrained tokens), brzmi: „DPoP jest włączony, więc granica dzierżawy (tenanta) jest egzekwowana”. Krótka odpowiedź brzmi: nie. RFC 9449, sekcja 4, odczytana 4 października 2026 r., mówi, że dowód DPoP wykazuje posiadanie klucza i sam w sobie nie jest mechanizmem uwierzytelniania ani kontroli dostępu. Ta sama sekcja mówi, że ważny token JWT dowodu DPoP sam nie wystarcza do podejmowania decyzji o kontroli dostępu.

Streszczenie na tej stronie ma węższe zadanie. Opisuje ograniczanie tokenów OAuth 2.0 do nadawcy za pomocą dowodu posiadania na poziomie aplikacji, co pozwala wykrywać ponowne użycie (replay) tokenów dostępu i tokenów odświeżania. Wykrywanie ponownego użycia nie jest uprawnieniem dzierżawy. Nie jest decyzją autoryzacyjną produktu. Mechanizm kontroli, który zauważa ponowne przedstawienie tokenu, nadal dotyczy tego tokenu, a nie jest rejestrem klientów, do których MSP ma prawo sięgać.

Dalsza część artykułu wyjaśnia, co dowód może oznaczać, jakie pokrewne rozróżnienia wprowadzają NIST SP 800-63-3 i OWASP Authorization Cheat Sheet, z jakimi sąsiednimi zagadnieniami nie należy go mylić i dlaczego token powiązany z dzierżawą nadal nie jest uprawnieniem. Tekst pozostaje na poziomie standardu: nie ma tu przykładowych dowodów, kluczy, ciągów tokenów ani konstrukcji nagłówków.

Sekcja 4 to punkt, którego żaden czytelnik nie powinien przeoczyć, więc powtórzmy go innymi słowami. Dowód DPoP pokazuje posiadanie klucza. Sam w sobie nie jest uwierzytelnieniem. Sam w sobie nie jest mechanizmem kontroli dostępu. Ważny token JWT dowodu sam nie wystarcza do decyzji o kontroli dostępu. Gdy dowód jest przedstawiany razem z tokenem dostępu powiązanym z kluczem, RFC odsyła w tym przypadku do sekcji 7.1, a dodatkowa pewność polega na tym, że klient przedstawiający token posiada klucz. Pewność co do przedstawienia tokenu to wciąż nie mapa klientów MSP. Posiadanie klucza nie wskazuje dzierżawy, nie wymienia użytkowników tej dzierżawy i nie zatwierdza działania na obiekcie w jej obrębie.

Streszczenie i wstęp razem opisują mechanizm, który ogranicza tokeny dostępu i tokeny odświeżania do nadawcy oraz wspiera wykrywanie ponownego użycia. Wstęp mówi też, że samo DPoP nie służy do uwierzytelniania klienta, choć można go używać niezależnie od tego, jak klient się uwierzytelnia. Klienci publiczni są na tej stronie jednym z głównych zastosowań. To przeciwieństwo stwierdzenia „DPoP zalogował użytkownika”. Dowód, który podróżuje razem z tokenem, ogranicza to, kto może przedstawić token. Nie jest logowaniem ani katalogiem.

Sekcja 3 w ogólnym zarysie: dowód to podpisany token JWT wysyłany z żądaniem, a serwer zasobów nadal musi uznać token za ważny pod każdym innym względem. „Ważny pod każdym innym względem” to przypomnienie dla kupującego: podpis i posiadanie klucza nie zastępują sprawdzenia terminu ważności, odbiorcy (audience) ani własnej decyzji aplikacji. To osobne mechanizmy kontroli i dowód ich nie wchłania.

Sekcja 2 przedstawia cel jako klasę zabezpieczeń. Powiązanie ma ograniczyć użycie wyciekłego tokenu na okaziciela (bearer) przez strony, które nie posiadają klucza. Tokenów na okaziciela może użyć każdy, kto je ma; DPoP ma ograniczać nadawcę. RFC mówi też, że DPoP nie zastępuje bezpiecznego transportu.

Warto wymienić dwa ograniczenia z rozważań dotyczących bezpieczeństwa w RFC. Dowód nie chroni integralności całego żądania. Nonce dostarczany przez serwer to jeden z opcjonalnych sposobów, w jaki serwery mogą ograniczyć czas, przez który dowód pozostaje użyteczny. MSP, który potrzebuje projektu obsługi nonce, powinien go uzyskać z przeglądu implementacji własnego stosu.

NIST SP 800-63-3 to tekst pokrewny, który służy tu jako słownik. Strona SP 800-63-3, odczytana 4 października 2026 r., mówi, że uwierzytelnianie daje pewność, że wnioskujący posiada uwierzytelniacz powiązany z poświadczeniem. Uwierzytelnianie nie określa autoryzacji ani uprawnień dostępu; to osobna decyzja, poza zakresem tych wytycznych. Strony ufające (relying parties) mogą wykorzystywać uwierzytelnioną tożsamość i atrybuty, a także inne czynniki, do podejmowania decyzji autoryzacyjnych. Strona ufająca ostatecznie rozstrzyga, czy asercja spełnia jej kryteria dostępu do systemu, niezależnie od poziomów pewności zdefiniowanych w tych wytycznych. Ten artykuł korzysta tylko z tego rozróżnienia; poziomy pewności to osobny temat.

OWASP Authorization Cheat Sheet, odczytany 4 października 2026 r., definiuje autoryzację jako sprawdzenie, czy żądane działanie jest zatwierdzone dla określonego podmiotu, i stwierdza, że autoryzacja różni się od uwierzytelniania. Zaleca domyślną odmowę, zasadę najmniejszych uprawnień i sprawdzanie każdego żądania. Ostrzega, że wbudowany mechanizm sprawdzania we frameworku może być niewłaściwy dla danej aplikacji. To kluczowe zdanie o punkcie decyzyjnym w tym artykule: dowód na poziomie protokołu nie jest zatwierdzeniem przez aplikację działania w zakresie dzierżawy. Biblioteka, która akceptuje dowód, wykonała zadanie biblioteki. Aplikacja wciąż musi zdecydować, czy ten wywołujący może dotknąć tego obiektu.

Zestawmy te trzy źródła obok siebie z perspektywy MSP. DPoP może ograniczyć, który klucz może przedstawić token. NIST mówi, że nawet udane uwierzytelnienie nie jest autoryzacją. OWASP mówi, że decyzja autoryzacyjna należy do aplikacji, z domyślną odmową, przy każdym żądaniu. Żadne z nich nie jest rejestrem uprawnień dzierżawy klienta. Uprawnienie dzierżawy to rekord w produkcie: który klient, jakie działanie, jaki obiekt. Dowód, uwierzytelniacz i zasada z cheat sheetu mogą wpływać na to, jak ten rekord jest sprawdzany. Nie są tym rekordem.

To nie jest FAQ o weryfikacji tożsamości ani o ceremoniach powiązania uwierzytelniacza. DPoP nie jest ani jednym, ani drugim. Dowód, że klucz został użyty w chwili żądania, nie jest ceremonią, która ustaliła, kim jest dana osoba, więc nie klasyfikuj dowodu jako tej ceremonii.

Nie chodzi też o wstrzykiwanie asercji. DPoP to nie zdanie „asercja została przyjęta, więc decyzja dotycząca dzierżawy została podjęta”. Przyjęcie dowodu posiadania nie oznacza, że zadziałał punkt decyzyjny polityk dzierżawy. To różne zdarzenia.

Nie chodzi również o pamięć podręczną API tożsamości. Obiekt katalogu w pamięci podręcznej nie jest tym dowodem, a ten dowód nie jest pamięcią podręczną. Aktualność wiersza katalogu i posiadanie klucza odpowiadają na różne pytania. Trafienie w pamięci podręcznej nie pokazuje, że użyto klucza. Dowód nie odświeża katalogu.

To nie jest „był obecny claim kontekstu uwierzytelnienia”. Claimy opisujące, jak ktoś się uwierzytelnił, nie są uprawnieniem dzierżawy. Obecność kontekstu nie jest zatwierdzeniem klienta.

I to nie jest „odbiorca (audience) tokenu pasuje do API”. Ograniczenie odbiorcy to inny mechanizm kontroli. Pasujący odbiorca wskazuje zamierzonego adresata tokenu. Nie wskazuje dzierżawy klienta MSP. API, które jest gotowe przyjąć token, nadal może obsługiwać niewłaściwego klienta.

Dla kupującego liczy się to, że istnieją trzy osobne rekordy. Token technika MSP, token partnera i uprawnienie dzierżawy klienta to trzy rekordy. Ograniczenie tokenu technika do nadawcy nie tworzy uprawnienia klienta, nie wymienia użytkowników klienta i nie zastępuje sprawdzenia autoryzacji przez produkt na obiekcie, którego dotyczy działanie. Technik z dobrze powiązanym tokenem nadal może być poza zakresem klienta, którego właśnie zamierza otworzyć. Powiązanie utrudnia ponowne użycie tokenu. Nie zapisuje wiersza uprawnienia.

Ten artykuł nie twierdzi, że Auris ani żaden inny produkt Altovar wydaje tokeny powiązane przez DPoP lub weryfikuje dowody DPoP. Token maszynowy powiązany z jedną dzierżawą również nie jest dowodem DPoP: powiązanie z dzierżawą mówi, do której dzierżawy należy token, a nie że sprawdzono dowód ani że punkt decyzyjny produktu przyznał uprawnienie dzierżawy klienta.

Zdanie, które warto powtarzać: nie utożsamiaj stwierdzeń „przedstawiono dowód DPoP” albo „token maszynowy jest powiązany z dzierżawą” ze stwierdzeniem „ten klient MSP ma uprawnienie”.