DPoP for tjenesteeiere og API-eiere
Målgruppen for dette dokumentet er tjenesteeiere. Hvis du heller leter etter teknisk dokumentasjon om DPoP, kan du gå til DPoP for utviklere.
DPoP (Demonstrating Proof-of-Possesion at the Application Layer) er en utvidelse til OAuth 2.0, en av protokollene som HelseID bygger på. Denne utvidelsen gjør det mulig å validere hvor et Access-token kommer fra, noe som begrenser muligheten for tokentyveri. Formålet med dette dokumentet er å gi API-eiere et grunnlag for å vurdere bruk av DPoP i sine tjenester.
Bakgrunn
Sikring av ressurser (som for eksempel et API) med bruk av OAuth 2.0 har tradisjonelt vært gjort med bruk av såkalte Bearer-tokens. Et Bearer-token er et token som enhver som har tilgang til det kan bruke. Spesifikt vil anvendelsen av et Bearer-token ikke kreve at den som bruker tokenet legitimerer bruken ved et kryptografisk bevis.
Diagrammet under viser hvordan en angriper kan nyttiggjøre seg av et slikt tokentyveri:
DPoP kan i stor grad begrense sannsynligheten for et slikt angrep ved å binde et token til en hemmelighet som klienten besitter. Hemmeligheten til klienten er et nøkkelpar; den private nøkkelen er hemmelig, og den offentlige nøkkelen er synlig. Klienten putter den offentlige nøkkelen i det som kalles et DPoP-bevis. DPoP-beviset (1) signeres deretter med den private nøkkelen.
Når det mottar DPoP-beviset (1), kan HelseID utstede et DPoP-token. Et DPoP-token ser akkurat ut som et vanlig Access-token, men har i tillegg med et ekstra claim som inneholder en hash av den offentlige nøkkelen fra DPoP-beviset (1). På denne måten blir DPoP-tokenet bundet til hemmeligheten fra klienten.
Når klienten deretter skal kalle API-et, sender den med DPoP-tokenet pluss et nytt DPoP-bevis (2), som i tillegg til den offentlige nøkkelen også inneholder en hash av DPoP-tokenet. Dette beviset blir også signert med den private nøkkelen. På denne måten blir DPoP-beviset (2) bundet til DPoP-tokenet.
Kun etter at API-et har sjekket kryptografisk at begge disse bindingene er på plass, vil det levere ut data til klienten.
Diagrammet under viser i grove trekk hvordan denne flyten foregår:
Merk også at selv om Dr. Evil i eksempelet over skulle ha lagt ved et DPoP-bevis (z) i kallet til API-et, ville API-et også ha sjekket kryptografisk at dette falske DPoP-beviset ikke var bundet til DPoP-tokenet. Følgelig ville kallet fra Dr. Evil til API-et fortsatt blitt avvist.