DPoP

DPoP (Demonstrating Proof of Posssession in the Application Layer) er en effektiv mekanisme som beskytter mot tyveri av Access-tokens.

Bakgrunn

Sikring av ressurser (som for eksempel et REST-API) med bruk av OAuth 2.0 har tradisjonelt vært gjort med bruk av bearer-tokens. Et bearer-token er et token som enhver som har tilgang til det kan bruke. Spesifikt vil bruken av et bearer-token ikke kreve at den som bruker det legitimerer bruken ved et kryptografisk bevis.

Som en følge av dette er tokentyveri den største enkelttrusselen mot token-basert autentisering. DPoP retter opp dette problemet ved å sikre at kun den riktige mottakeren av et Access-token kan bruke dette tokenet mot et API.

Funksjonalitet

DPoP fungerer ved at klienten har tilgang til en hemmelighet (en privatnøkkel) som den må bruke både i kall mot Token-endepunktet i HelseID for å hente ut tokens og ved kall til et API hvor tokenet gir tilgang.

Ved uthenting av tokens fra HelseID vil klienten legge ved et DPoP-bevis, dette er i praksis en JWT signert med hemmeligheten til klienten. HelseID utsteder så et Access Token som inneholder et nytt claim, cnf, som forteller hvilket nøkkelpar som ble brukt. Senere når klienten ønsker å kalle et API legger de ved Access Tokenet men de legger også ved et nytt DPoP-bevis som dokumenterer at klienten har tilgang på den samme privatnøkkelen som tidligere.

sequenceDiagram participant Klient participant HelseID (Token-endepunkt) participant API Klient->>HelseID (Token-endepunkt): Ber om Access Token, legger ved DPoP-bevis HelseID (Token-endepunkt)->>Klient: Invalid Request, du må også legge ved nonce Klient->>HelseID (Token-endepunkt): Ber om Access Token, legger ved DPoP-bevis med nonce HelseID (Token-endepunkt)->>Klient: Access Token som inneholder cnf-claim Klient->>API: Kaller API, legger ved Access Token og DPoP-bevis API->>API: Verifiserer at DPoP-bevis stemmer med cnf-claim i Access Token. API->>Klient: Resultat av API-kall

Detaljert beskrivelse av DPoP-kall mot Token-endepunktet

Når du gjør et DPoP-kall mot Token-endepunktet, stilles det enkelte krav til innholdet i kallet.

Sikring av privatnøkkel

Privatnøkkelen som brukes til å signere DPoP-beviset, må sikres på samme måte som privatnøkkelen som brukes for klientautentisering. Dette er beskrevet i sikkerhetsprofilen: Bruk av hemmeligheter for klienter.

I kontekst av HelseID kan du sikre et DPoP-bevis på to forskjellige måter:

du kan bruke den samme privatnøkkelen som du bruker for å signere client assertion for klientautentisering eller
du kan generere nye nøkkelpar ved behov

Godkjente signeringsalgoritmer er beskrevet i sikkerhetsprofilen: Krav til kryptografi.

Formatering av et DPoP-bevis

DPoP-beviset må formateres på en bestemt måte; dette er beskrevet i sikkerhetsprofilen for HelseID: Formatering av DPoP-bevis.

Bruk av nonce

HelseID krever at klienten må gjøre to kall til token-endepunktet for å få utlevert et DPoP-token. Ved det første kallet vil HelseID gi tilbake HTTP-kode 400 med feilmelding use_dpop_nonce. Det blir lagt ved en header med navnet DPoP-Nonce som har en tilfeldig verdi som innhold. Denne verdien må innlemmes i et nytt DPoP-bevis, som blir vedlagt til det andre kallet til HelseID. En grundigere beskrivelse av denne funksjonaliteteten finner du i denne delen av spesifikasjonen.

Krav til API-ets sikring av DPoP-bevis

For at alt dette skal ha noen verdi, må API-et som validerer DPoP-tokenet også validere DPoP-beviset som følger med. Dette er beskrevet i sikkerhetsprofilen for HelseID: Validering av DPoP-bevis.