Ett DPoP-bevis visar att en nyckel har använts. Det berättigar inte en MSP-tenant

Ett DPoP-bevis visar att en nyckel har använts. Det berättigar inte en MSP-tenant

Meningen som en MSP hör från kunden efter att någon har aktiverat ”avsändarbegränsade tokens” är: ”DPoP är på, så tenantgränsen upprätthålls.” Det korta svaret är nej. RFC 9449, avsnitt 4, läst den 4 oktober 2026, säger att ett DPoP-bevis visar innehav av en nyckel och i sig inte är en mekanism för autentisering eller åtkomstkontroll. Samma avsnitt säger att en giltig DPoP-bevis-JWT inte ensam räcker för att fatta beslut om åtkomstkontroll.

Sammanfattningen på den sidan har en snävare uppgift. Den beskriver hur OAuth 2.0-tokens begränsas till avsändaren med ett innehavsbevis på applikationsnivå, vilket gör det möjligt att upptäcka återuppspelning av access tokens och refresh tokens. Att upptäcka återuppspelning är inte en tenantbehörighet. Det är inte ett auktoriseringsbeslut i en produkt. En kontroll som märker att en token visas upp igen är fortfarande en kontroll av just den token, inte ett register över vilka kunder en MSP får röra.

Resten av texten går igenom vad beviset får betyda, vilka närliggande distinktioner NIST SP 800-63-3 och OWASP Authorization Cheat Sheet gör, vilka angränsande frågor det inte ska förväxlas med och varför en token som är bunden till en tenant ändå inte är en behörighet. Texten håller sig på standardens nivå: här finns inga exempelbevis, nycklar, tokensträngar eller headerkonstruktioner.

Avsnitt 4 är den punkt som ingen läsare bör missa, så här kommer den igen med andra ord. Ett DPoP-bevis visar innehav av en nyckel. I sig är det inte autentisering. I sig är det inte en mekanism för åtkomstkontroll. En giltig bevis-JWT räcker inte ensam för ett beslut om åtkomstkontroll. När ett bevis visas upp tillsammans med en nyckelbunden access token hänvisar RFC:n till avsnitt 7.1 för det fallet, och den extra försäkran är att klienten som visar upp token innehar nyckeln. En försäkran om uppvisandet är ändå ingen karta över MSP:ns kunder. Att inneha nyckeln pekar inte ut en tenant, listar inte den tenantens användare och godkänner inte en åtgärd på ett objekt inom tenanten.

Sammanfattningen och inledningen beskriver tillsammans en mekanism som begränsar access tokens och refresh tokens till avsändaren och som stöder upptäckt av återuppspelning. Inledningen säger också att DPoP i sig inte används för klientautentisering, även om det kan användas oavsett hur klienten autentiserar sig. Publika klienter är ett av de främsta användningsfallen på den sidan. Det är motsatsen till ”DPoP loggade in användaren”. Ett bevis som följer med en token är en begränsning av vem som kan visa upp token. Det är inte inloggningen och inte katalogen.

Avsnitt 3 i stora drag: beviset är en signerad JWT som skickas med begäran, och resursservern måste fortfarande bedöma token som giltig i alla andra avseenden. ”Giltig i alla andra avseenden” är påminnelsen till köparen: signatur och innehav ersätter inte utgångstid, audience eller applikationens eget beslut. Det är separata kontroller, och ett bevis tar inte över dem.

Avsnitt 2 beskriver målet som en klass av skydd. Bindningen ska begränsa användningen av en läckt bearer token av parter som inte innehar nyckeln. Bearer tokens kan användas av den som har dem; DPoP ska begränsa avsändaren. RFC:n säger också att DPoP inte ersätter en säker transport.

Två begränsningar ur RFC:ns säkerhetsöverväganden är värda att nämna. Ett bevis skyddar inte integriteten för hela begäran. En nonce som servern tillhandahåller är ett valfritt sätt för servrar att begränsa hur länge ett bevis går att använda. En MSP som behöver en nonce-design bör få den från en implementationsgranskning av sin egen stack.

NIST SP 800-63-3 är närliggande och fungerar här som ordbok. Sidan för SP 800-63-3, läst den 4 oktober 2026, säger att autentisering skapar förtroende för att den sökande innehar en autentiserare som är bunden till identitetsuppgiften. Autentisering avgör inte behörigheter eller åtkomsträttigheter; det är ett separat beslut som ligger utanför riktlinjernas räckvidd. Förlitande parter (relying parties) får använda en autentiserad identitet och attribut, plus andra faktorer, för att fatta auktoriseringsbeslut. Den förlitande parten avgör i sista hand om ett intyg uppfyller dess kriterier för systemåtkomst, oavsett vilka tillitsnivåer riktlinjerna definierar. Den här artikeln använder bara den distinktionen; tillitsnivåer är ett separat ämne.

OWASP Authorization Cheat Sheet, läst den 4 oktober 2026, definierar auktorisering som att verifiera att en begärd åtgärd är godkänd för en specifik entitet, och säger att auktorisering skiljer sig från autentisering. Den förespråkar nekande som standard, minsta möjliga behörighet och en kontroll vid varje begäran. Den varnar för att ett ramverks inbyggda kontroll kan vara fel kontroll för applikationen. Det är meningen om beslutspunkten i den här artikeln: ett protokollbevis är inte applikationens godkännande av en åtgärd inom en tenant. Ett bibliotek som accepterar ett bevis har gjort bibliotekets jobb. Applikationen måste fortfarande avgöra om den här anroparen får röra det här objektet.

Ställ de tre bredvid varandra för en MSP. DPoP kan begränsa vilken nyckel som får visa upp en token. NIST säger att inte ens en lyckad autentisering är auktoriseringen. OWASP säger att auktoriseringsbeslutet är applikationens sak, med nekande som standard, vid varje begäran. Ingen av de tre är ett behörighetsregister för en kundtenant. En tenantbehörighet är en post i produkten: vilken kund, vilken åtgärd, vilket objekt. Ett bevis, en autentiserare och en princip ur ett cheat sheet kan påverka hur den posten kontrolleras. De är inte posten.

Det här är ingen FAQ om identitetsprövning eller ceremonier för autentiserarbindning. DPoP är ingetdera. Ett bevis på att en nyckel användes vid tidpunkten för begäran är ingen ceremoni som har fastställt vem en person är, så sortera inte in beviset under den ceremonin.

Den handlar inte heller om injektion av intyg. DPoP är inte meningen ”ett intyg accepterades, alltså kördes tenantbeslutet”. Att acceptera ett innehavsbevis betyder inte att en beslutspunkt för tenantpolicyer har körts. Det är olika händelser.

Den handlar inte heller om cachning av identitets-API:er. Ett cachat katalogobjekt är inte det här beviset, och det här beviset är ingen cache. Hur färsk en katalograd är och innehav av en nyckel besvarar olika frågor. En cacheträff visar inte att en nyckel användes. Ett bevis uppdaterar inte en katalog.

Det är inte ”ett anspråk om autentiseringskontext fanns med”. Anspråk som beskriver hur någon autentiserade sig är ingen tenantbehörighet. Att det finns kontext är inget godkännande av en kund.

Och det är inte ”tokens audience matchar API:et”. Audiencebegränsning är en annan kontroll. En matchande audience anger en avsedd mottagare av token. Den anger inte MSP:ns kundtenant. Ett API som är villigt att ta emot token kan ändå betjäna fel kund.

Det som spelar roll för köparen är att det finns tre separata poster. En token för en MSP-tekniker, en partnertoken och en kundtenants behörighet är tre poster. Att begränsa teknikerns token till avsändaren skapar inte kundens behörighet, listar inte kundens användare och ersätter inte produktens auktoriseringskontroll av objektet som berörs. En tekniker med en väl bunden token kan ändå stå utanför den kund som teknikern är på väg att öppna. Bindningen gör token svårare att spela upp igen. Den skriver inte behörighetsraden.

Den här artikeln påstår inte att Auris, eller någon annan Altovar-produkt, utfärdar DPoP-bundna tokens eller validerar DPoP-bevis. En maskintoken som är bunden till en enda tenant är inte heller något belägg för DPoP: tenantbindningen anger vilken tenant token tillhör, inte att ett bevis har kontrollerats eller att en beslutspunkt i produkten har beviljat en kundtenant behörighet.

Meningen att upprepa: likställ inte ”ett DPoP-bevis visades upp” eller ”en maskintoken är bunden till tenanten” med ”den här MSP-kunden är behörig”.