DPoP (Demonstrating Proof-of-Possession)

DPoP knytter et access token kryptografisk til en bestemt klients private nøkkel. Tenk på det som en digital signatur som bare den rettmessige klienten kan opprette.

Her er hovedideen:

• Klienten genererer et unikt nøkkelpar.
• Den offentlige nøkkelen knyttes til access tokenet.
• Klienten «beviser at den har» den private nøkkelen med hver forespørsel.

Prosessen starter med at klientapplikasjonen genererer et asymmetrisk kryptografisk nøkkelpar. Det betyr at den oppretter både en privat nøkkel og en offentlig nøkkel.

• Den private nøkkelen holdes hemmelig av klienten.
• Den offentlige nøkkelen kan deles uten at sikkerheten svekkes.

Dette nøkkelparet er unikt for klientøkten eller klientinstansen.

Når klienten ber om et access token fra Authorization Server, inkluderer den en spesialheader kalt DPoP i forespørselen.

Denne DPoP-headeren inneholder en JSON Web Token (JWT) signert med klientens private nøkkel. Denne JWT-en inneholder en hash av klientens offentlige nøkkel.

JWT-en i DPoP-headeren er «beviset på at nøkkelen finnes hos klienten». Den inneholder flere claims:

• jkt: JSON Web Key Thumbprint for klientens offentlige nøkkel.
• htm: HTTP-metoden for forespørselen (for eksempel GET eller POST).
• htu: HTTP-URL-en for forespørselen.
• iat: Tidspunktet da tokenet ble utstedt, noe som hindrer replay-angrep.

Authorization Server validerer denne JWT-en og knytter jkt til det utstedte access tokenet.

Når klienten har mottatt et DPoP-bundet access token, bruker den det til å få tilgang til beskyttede ressurser på Resource Server.

For hver forespørsel til Resource Server må klienten sende en ny DPoP-header med en fersk JWT, signert med den private nøkkelen, som samsvarer med den aktuelle forespørselens htm og htu.

Resource Server utfører flere kritiske kontroller:

1. Den verifiserer signaturen til DPoP-JWT-en ved hjelp av den offentlige nøkkelen som utledes fra jkt-claimen.
2. Den kontrollerer at jkt i DPoP-JWT-en samsvarer med jkt som er lagret i selve access tokenet.
3. Den kontrollerer at claimene htm og htu i DPoP-JWT-en samsvarer med den faktiske HTTP-forespørselen.

Hvis en kontroll mislykkes, nektes tilgang. Dette sikrer at bare klienten som har den private nøkkelen, kan bruke tokenet.

Du lurer kanskje på Mutual TLS (mTLS). Både DPoP og mTLS knytter token til en klient, men de opererer på ulike lag:

• mTLS: Knytter token på TLS-laget (transportlaget) ved hjelp av klientsertifikater.
• DPoP: Knytter token på applikasjonslaget ved hjelp av kryptografiske bevis i HTTP-headere.

DPoP er ofte mer fleksibelt og enklere å implementere for et bredere utvalg klienttyper (særlig offentlige klienter som mobilapper) enn mTLS.

Gratulerer! Du har lært om DPoP, en kraftig sikkerhetsmekanisme.

DPoP forbedrer OAuth2 og OIDC ved å knytte access token kryptografisk til klientens private nøkkel. Dermed hindres eksfiltrering av token effektivt, og stjålne token blir ubrukelige for angripere.

Dette «beviset på at nøkkelen finnes hos klienten» styrker sikkerheten i applikasjonene dine betydelig ved å sikre at bare den legitime klienten kan bruke access tokenene sine.