DPoP (Demonstrating Proof-of-Possession)

DPoP koppelt een toegangstoken cryptografisch aan de privésleutel van een specifieke client. Je kunt dit zien als een digitale handtekening die alleen de rechtmatige client kan maken.

Dit is het kernidee:

• De client genereert een uniek sleutelpaar.
• De openbare sleutel wordt aan het toegangstoken gekoppeld.
• De client 'bewijst het bezit' van de privésleutel bij elk verzoek.

Het proces begint met de clientapplicatie, die een asymmetrisch cryptografisch sleutelpaar genereert. Dit betekent dat de client zowel een privésleutel als een openbare sleutel maakt.

• De privésleutel wordt geheimgehouden door de client.
• De openbare sleutel kan worden gedeeld zonder de beveiliging in gevaar te brengen.

Dit sleutelpaar is uniek voor de clientsessie of het clientexemplaar.

Wanneer de client een toegangstoken aanvraagt bij de autorisatieserver, voegt de client een speciale header met de naam DPoP toe aan het verzoek.

Deze DPoP-header bevat een JSON Web Token (JWT) dat is ondertekend met de privésleutel van de client. Dit JWT bevat een hash van de openbare sleutel van de client.

Het JWT in de DPoP-header is het 'bewijs van bezit'. Het bevat verschillende claims:

• jkt: de JSON Web Key Thumbprint van de openbare sleutel van de client.
• htm: de HTTP-methode van het verzoek (bijvoorbeeld GET of POST).
• htu: de HTTP-URL van het verzoek.
• iat: het tijdstip van uitgifte, waarmee herhaling wordt voorkomen.

De autorisatieserver valideert dit JWT en koppelt de jkt aan het uitgegeven toegangstoken.

Zodra de client een aan DPoP gekoppeld toegangstoken ontvangt, gebruikt de client dit om toegang te krijgen tot beveiligde bronnen op de resourceserver.

Bij elk verzoek aan de resourceserver moet de client opnieuw een nieuwe DPoP-header meesturen met een vers JWT. Dit JWT is ondertekend met de privésleutel van de client en komt overeen met de htm en htu van het huidige verzoek.

De resourceserver voert kritieke controles uit:

1. De server verifieert de handtekening van het DPoP-JWT met de openbare sleutel die is afgeleid van de claim jkt.
2. De server controleert of de jkt in het DPoP-JWT overeenkomt met de jkt die in het toegangstoken zelf is opgeslagen.
3. De server controleert of de claims htm en htu in het DPoP-JWT overeenkomen met het werkelijke HTTP-verzoek.

Als een controle mislukt, wordt de toegang geweigerd. Zo kan alleen de client die over de privésleutel beschikt het token gebruiken.

Je vraagt je misschien af hoe Mutual TLS (mTLS) hierin past. Zowel DPoP als mTLS koppelt tokens aan een client, maar ze werken op verschillende lagen:

• mTLS: koppelt op de TLS- (transport)laag met clientcertificaten.
• DPoP: koppelt op de applicatielaag met cryptografische bewijzen in HTTP-headers.

DPoP is vaak flexibeler en eenvoudiger te implementeren voor een groter aantal clienttypen (vooral openbare clients zoals mobiele apps) dan mTLS.

Gefeliciteerd! Je hebt geleerd over DPoP, een krachtig beveiligingsmechanisme.

DPoP verbetert OAuth2 en OIDC door toegangstokens cryptografisch aan de privésleutel van de client te koppelen. Hierdoor wordt tokenexfiltratie effectief voorkomen en kunnen aanvallers gestolen tokens niet gebruiken.

Dit 'bewijs van bezit' versterkt de beveiliging van je applicaties aanzienlijk, omdat alleen de legitieme client zijn toegangstokens kan gebruiken.