Sikkerhetsvurderinger for API som bruker DPoP

Dette dokumentet beskriver hvordan et API skal forholde seg til bruk av DPoP, både med tanke på generelle sikkerhetstiltak og hvordan DPoP-tokens og DPoP-bevis skal håndteres og valideres.

Generelle sikkerhetstiltak

Når et API-endepunkt er satt opp for autorisasjon ved DPoP-tokens, SKAL det ikke godta Bearer-tokens i Authorization-headeren, det skal bare godta DPoP-tokens. Med andre ord: når headeren Authorization: DPoP [token] blir brukt i kall mot API-endepunktet, skal kall med headeren: Authorization: Bearer [token] ikke godtas.

Årsaken til dette er at et DPoP-token er bakoverkompatibelt med tradisjonelle Bearer-tokens, noe som gjør API-et åpent for angrep dersom samme endepunkt godtar begge typer tokens. For å sikre et API med både Bearer-tokens og DPoP-tokens, KAN API-et godta Bearer-tokens i et (annet) endepunkt som ikke godtar DPoP-tokens.

Hvis API-et vil sikre forskjellige endepunkter med både Bearer-tokens og DPoP-tokens, SKAL det bruke et eget scope for å skille mellom ressurser som er beskyttet av DPoP og ressurser som er beskyttet av tradisjonelle Bearer-tokens.

API-ets validering av DPoP-bevis

I tillegg at et API MÅ gjøre en normal validering av et Access-token, må et API som bruker DPoP også gjøre spesielle valideringer for at mekanismen skal gi verdi. Hvis du bruker et biblotek for validering av DPoP-bevis, vil dette være funksjonalitet som er inneholdt i biliotekskoden. Hvis ikke, må følgende valideringer gjøres:

  1. At Authorization-headeren inneholder et DPoP-token. Dette gjøres ved å sjekke at verdien i headeren starter med teksten DPoP.

  2. At Access-tokenet er gyldig i henhold til de generelle valideringsreglene for Access-token som er beskrevet her.

  3. At Access-tokenet er et DPoP-token ved å sjekke at det inneholder claimet cnf.

  4. At et DPoP-bevis er inkludert i DPoP-headeren. Merk at navn på headere ikke er case-sensitive, så for eksempel DPOP og dpop er også gyldige navn.

  5. At det ikke er mer enn en DPoP-header i HTTP-forespørselen.

  6. At DPoP-beviset er strukturert som som en JWT beskrevet i dette vedlegget.

  7. At signaturen til DPoP-beviset stemmer med den offentlige nøkkelen som finnes i cnf-claimet i DPoP-bevisets header.

  8. At jwk-headeren i DPoP-beviset ikke inneholder en symmetrisk nøkkel.

  9. At claimene htm og htu i DPoP-beviset stemmer med HTTP-metode og Url for API-kallet som gjennomføres.

  10. At iat-claimet i DPoP-beviset peker til et tidspunkt som ikke er mer enn 10 sekunder tilbake i tid.

  11. At jti-claimet i DPoP-beviset har en verdi som er unik innenfor levetiden til et DPoP-bevis (10 sekunder, se punkt 8).

  12. At verdien til ath-claimet i DPoP-beviset stemmer med en kryptografisk hash av Access Tokenet. Verdien beregnes som følger: The base64url encoded SHA-256 hash of the ASCII encoding of the associated access token's value.

  13. At verdien til cnf-claimet i Access-tokenet matcher den offentlige nøkkelen til DPoP-beviset.