DPoP: Hvorfor vi stiller kravene om ulike endepunkt og ulike scopes

HelseID stiller krav om at API-er som skal støtte både DPoP-tokens og Bearer-tokens må gjøre dette ved å tilby to ulike endepunkter og to ulike scopes.

Vi forsøker å forklare årsaken til dette kravet her, men dette dokumentet gir en mer utfyllende forklaring.

NB: Nye API-er skal kun støtte DPoP og trenger ikke å oppfylle disse kravene.

Krav om nye endepunkter og nye scopes for API-er som går over fra Bearer-tokens til DPoP-tokens

Dette dokumentet tar for seg kravene HelseID stiller for eksisterende API-er som skal ta i bruk DPoP som sikkerhetsmekanisme. I disse API-ene vil både DPoP-tokens og Bearer-tokens støttes i en overgangsperiode; dette vil medføre høyere kompleksitet i tilgangsstyringen. Det kan også være en risiko for at innføringen av DPoP ikke gir verdi i overgangsfasen dersom API-et ikke følger kravene som HelseID stiller.

HelseID krever at alle API-er som skal støtte både DPoP-tokens og Bearer-tokens må etablere et nytt endepunkt for DPoP. De må også opprette et nytt scope som indikerer at klienten ønsker å bruke DPoP mot API-et.

Kravene har to formål:

• Å sikre at tilgangsstyringen i API-et blir så enkel som mulig
• Å sikre at API-et er beskyttet mot såkalte «downgrade-angrep» som beskrevet i RFC 9449.

Krav om to ulike endepunkter

HelseID krever at API-et må tilby ulike endepunkter for tilgang med DPoP-tokens og Bearer-tokens. Dette er en utvidelse av sikkerhetskrav SA1 hvor vi krever at endepunkter i API-et som godtar Access-tokens ikke skal støtte andre sikkerhetsmekanismer.

Dette kravet stilles for å redusere kompleksiteten i tilgangstyringen til API-et. Kravene til HelseID er generelle og basert på beste praksis. Målet er å redusere sannsynligheten for svakheter i økosystemet snarere enn i hvert enkelt API.

Krav om to ulike scopes

Når et eksisterende API skal ta i bruk DPoP så vil API-et i en periode måtte støtte både DPoP-tokens og Bearer-tokens, fram til alle klientene har tatt i bruk DPoP. Vi legger til grunn at API-eieren ønsker å få gevinst av DPoP så snart som mulig, også i overgangsperioden.

Et DPoP-token kan også brukes som et Bearer-token, hensikten med dette er å kunne gradvis innføre DPoP-mekanismen. En klient kan da selv oppgradere til DPoP uten at hvert enkelt API som klienten konsumerer trenger å gjøre endringer for sine klienter.

Dette er en stor fordel, men det medfører en ulempe. Et API kan ikke vite om klienten mener å bruke DPoP-tokenet som et Bearer-token, eller om det er et angrep der noen forsøker å misbruke (nedgradere) et token på avveie.

For å løse dette problemet krever vi at API-ene innfører et nytt scope som indikerer bruk av DPoP. På denne måten kan API-et skille mellom normal oppførsel fra en klient, og et angrep. HelseID stiller ingen krav til navngivingen av de to scopene utover at de er unike.

Figur 1

En angriper stjeler et DPoP-token mot et API som tillater både DPoP-token og Bearer-token i samme endepunkt. Angriperen kan da nedgradere DPoP-tokenet til et Bearer-token og får tilgang til API-et. I dette tilfellet gir ikke DPoP verdi.

Figur 2

En angriper stjeler et DPoP-token mot et API som støtter både DPoP-token og Bearer-token, men med to ulike endepunkter. Angriperen kan da nedgradere DPoP-tokenet til et Bearer-token og får tilgang til API-et gjennon endepunktet som støtter Bearer-tokens. I dette tilfellet gir heller ikke DPoP verdi.

Figur 3

En angriper stjeler et DPoP-token mot et API som tillater både DPoP-token og Bearer-token i samme endepunkt, men her bruker API-et to ulike scopes for å beskrive hensikten med tokenet. Angriperen kan nedgradere DPoP-tokenet til et Bearer-token, men vil ikke få tilgang siden kombinasjonen av Bearer-token og DPoP-scope ikke tillates av API-et. Her vil DPoP gi verdi, men løsningen krever en kompleks tilgangsstyring i API-et så det er høy risiko for feil.

Figur 4

En angriper stjeler et DPoP-token mot et API ssom støtter både DPoP-token og Bearer-token, men i to ulike endepunkter. I tillegg bruker API-et to ulike scopes for å beskrive hensikten med tokenet. Angriperen kan nedgradere DPoP-tokenet til et Bearer-token, men vil ikke få tilgang siden kombinasjonen av Bearer-token og DPoP-scope ikke tillates av API-et. Her vil DPoP gi verdi, og tilgangsstyringen i API-et er så enkel som mulig.