Una proof DPoP mostra che una chiave è stata usata. Non dà diritto a un tenant MSP

Una proof DPoP mostra che una chiave è stata usata. Non dà diritto a un tenant MSP

La frase che un MSP sente dal cliente dopo che qualcuno ha attivato i «token vincolati al mittente» è: «DPoP è attivo, quindi il confine di tenant è applicato». La risposta breve è no. La RFC 9449, sezione 4, letta il 4 ottobre 2026, dice che una proof DPoP dimostra il possesso di una chiave e, da sola, non è un meccanismo di autenticazione né di controllo degli accessi. La stessa sezione dice che un JWT di proof DPoP valido non basta da solo per prendere decisioni di controllo degli accessi.

L’abstract di quella pagina ha un compito più ristretto. Descrive il vincolo al mittente dei token OAuth 2.0 tramite una proof of possession a livello applicativo, che permette di rilevare il replay di access token e refresh token. Il rilevamento del replay non è un diritto di tenant. Non è una decisione di autorizzazione di prodotto. Un controllo che si accorge che un token viene presentato di nuovo resta un controllo su quel token, non un registro di quali clienti un MSP sia autorizzato a toccare.

Il resto dell’articolo spiega che cosa la proof può significare, quali distinzioni affini tracciano NIST SP 800-63-3 e l’OWASP Authorization Cheat Sheet, con quali questioni vicine non va confusa e perché un token vincolato al tenant non è comunque un diritto. Resta al livello dello standard: qui non ci sono proof di esempio, chiavi, stringhe di token né costruzione degli header.

La sezione 4 è il punto che chi legge non deve perdere, quindi eccolo di nuovo con altre parole. Una proof DPoP mostra il possesso di una chiave. Da sola non è autenticazione. Da sola non è un meccanismo di controllo degli accessi. Un JWT di proof valido non basta da solo per una decisione di controllo degli accessi. Quando una proof è presentata insieme a un access token vincolato alla chiave, la RFC rimanda per quel caso alla sezione 7.1, e la garanzia aggiuntiva è che il client che presenta il token possiede la chiave. Una garanzia sulla presentazione non è comunque una mappa dei clienti MSP. Possedere la chiave non nomina un tenant, non elenca gli utenti di quel tenant e non approva un’azione su un oggetto all’interno del tenant.

L’abstract e l’introduzione, presi insieme, descrivono un meccanismo che vincola al mittente access token e refresh token e che supporta il rilevamento del replay. L’introduzione dice anche che DPoP di per sé non serve ad autenticare il client, anche se può essere usato a prescindere da come il client si autentica. I client pubblici sono uno dei casi d’uso principali indicati in quella pagina. È l’opposto di «DPoP ha fatto il login dell’utente». Una proof che viaggia con un token è un vincolo su chi può presentare il token. Non è il login e non è la directory.

La sezione 3, a grandi linee: la proof è un JWT firmato inviato con la richiesta, e il resource server deve comunque trovare il token valido sotto ogni altro aspetto. «Valido sotto ogni altro aspetto» è il promemoria per il cliente: firma e possesso non sostituiscono la scadenza, l’audience o la decisione propria dell’applicazione. Sono controlli separati, e una proof non li assorbe.

La sezione 2 enuncia l’obiettivo come classe di difesa. Il vincolo serve a limitare l’uso di un bearer token trapelato da parte di chi non possiede la chiave. I bearer token sono utilizzabili da chiunque li detenga; DPoP serve a vincolare il mittente. La RFC dice anche che DPoP non sostituisce un trasporto sicuro.

Due limiti indicati nelle considerazioni di sicurezza della RFC meritano di essere nominati. Una proof non protegge l’integrità dell’intera richiesta. Un nonce fornito dal server è un modo opzionale con cui i server limitano per quanto tempo una proof resta utilizzabile. Un MSP che ha bisogno di progettare i nonce dovrebbe ricavarlo da una revisione dell’implementazione del proprio stack.

NIST SP 800-63-3 è un riferimento affine, e qui serve da dizionario. La pagina SP 800-63-3, letta il 4 ottobre 2026, dice che l’autenticazione stabilisce la fiducia che il richiedente possieda un authenticator vincolato alla credenziale. L’autenticazione non determina autorizzazioni né privilegi di accesso: è una decisione separata, fuori dall’ambito di quelle linee guida. I relying party possono usare un’identità autenticata e degli attributi, più altri fattori, per prendere decisioni di autorizzazione. Il relying party è l’arbitro finale sul fatto che un’asserzione soddisfi i suoi criteri di accesso al sistema, a prescindere dai livelli di assurance definiti da quelle linee guida. Questo articolo usa solo questa distinzione; i livelli di assurance sono un tema a parte.

L’OWASP Authorization Cheat Sheet, letto il 4 ottobre 2026, definisce l’autorizzazione come la verifica che un’azione richiesta sia approvata per un’entità specifica, e dice che l’autorizzazione è distinta dall’autenticazione. Sostiene il diniego di default, il privilegio minimo e un controllo a ogni richiesta. Avverte che il controllo integrato di un framework può essere quello sbagliato per l’applicazione. È questa la frase sul punto di decisione per questo articolo: una proof di protocollo non è l’approvazione, da parte dell’applicazione, di un’azione nell’ambito di un tenant. Una libreria che accetta una proof ha fatto il lavoro della libreria. L’applicazione deve ancora decidere se questo chiamante può toccare questo oggetto.

Mettiamo i tre riferimenti uno accanto all’altro per un MSP. DPoP può vincolare quale chiave può presentare un token. NIST dice che anche un’autenticazione riuscita non è l’autorizzazione. OWASP dice che la decisione di autorizzazione spetta all’applicazione, con diniego di default, a ogni richiesta. Nessuno dei tre è un registro dei diritti del tenant cliente. Un diritto di tenant è un registro di prodotto: quale cliente, quale azione, quale oggetto. Una proof, un authenticator e un principio di un cheat sheet possono orientare il modo in cui quel registro viene controllato. Non sono il registro.

Questa non è una FAQ sull’identity proofing o sulle cerimonie di binding dell’authenticator. DPoP non è né l’una né l’altra cosa. Una proof che una chiave è stata usata al momento della richiesta non è una cerimonia che ha stabilito chi è una persona, quindi non archiviare la proof sotto quella cerimonia.

Non parla nemmeno di iniezione di asserzioni. DPoP non equivale alla frase «un’asserzione è stata accettata, quindi la decisione sul tenant è stata eseguita». Accettare una proof of possession non significa che un punto di decisione delle policy di tenant sia entrato in funzione. Sono eventi diversi.

Non riguarda neppure la cache delle API di identità. Un oggetto di directory in cache non è questa proof, e questa proof non è una cache. L’aggiornamento di una riga di directory e il possesso di una chiave rispondono a domande diverse. Un cache hit non mostra che una chiave è stata usata. Una proof non aggiorna una directory.

Non è «era presente un claim sul contesto di autenticazione». I claim che descrivono come qualcuno si è autenticato non sono un diritto di tenant. La presenza di un contesto non è l’approvazione di un cliente.

E non è «l’audience del token corrisponde all’API». La restrizione dell’audience è un controllo diverso. Un’audience corrispondente nomina un destinatario previsto del token. Non nomina il tenant cliente dell’MSP. Un’API disposta ad accettare il token può comunque servire il cliente sbagliato.

Per il cliente conta che i registri sono tre e sono separati. Un token del tecnico MSP, un token del partner e un diritto di tenant cliente sono tre registri. Vincolare al mittente il token del tecnico non crea il diritto del cliente, non elenca gli utenti del cliente e non sostituisce il controllo di autorizzazione del prodotto sull’oggetto toccato. Un tecnico con un token ben vincolato può comunque trovarsi fuori dal cliente che sta per aprire. Il vincolo rende il token più difficile da riutilizzare. Non scrive la riga del diritto.

Questo articolo non afferma che Auris, o qualsiasi altro prodotto Altovar, emetta token vincolati con DPoP o verifichi proof DPoP. Nemmeno un token macchina vincolato a un singolo tenant è una prova di DPoP: il vincolo al tenant dice a quale tenant appartiene il token, non che una proof sia stata verificata né che un punto di decisione di prodotto abbia concesso un diritto di tenant cliente.

La frase da ripetere: non equiparare «è stata presentata una proof DPoP» o «un token macchina è vincolato al tenant» a «questo cliente MSP ha il diritto».