search

FHIDev / fhi.helseid

Fhi.HelseId component for accessing NHN HelseId
MIT License
7 stars 5 forks source link

Vi må støtte Authentication type DPoP for å gjøre overgangen til å bruke DPoP mer smidig. #401

Closed martsve closed 3 months ago

martsve commented 3 months ago

DPoP tokens er bakoverkompatible, men de har en ny type. I stede for "Bearer" har de type "DPoP".

Vi må legge til støtte i HelseId-pakken for å godta "DPoP" som type, selv om vi bruker gammel Bearer-validering.

Om vi ikke legger inn denne støtten vil vi få et problem der både Server og Klient må ta i bruk DPoP SAMTIDIG når det aktiveres. Det vil være vanskelig å kordinere. Vi må derfor la følgende kunne skje:

  1. Server tar i bruk ny HelseId pakke som støtter "DPoP" token, men validerer det som Bearer token
  2. Klientene oppdaterer HelseId/ClientCredentials pakkene til å støtte DPoP og tar det i bruk ved å sette config-verdi.
  3. Serveren kan så slå på DPoP validering. Den vil da nekte Bearer tokens og kun slippe inn DPoP tokens.

bilde

martsve commented 3 months ago

@yne-bv Jeg tenker vi kunne sett på denne oppgaven så vi får satt opp pakkene til å spille fint med hverandre. Om vi får ut en helseId-pakke som tillatter DPoP token får vi testet ClientCredentials pakken.

Ashildbaukhol commented 3 months ago

Se også #364

martsve commented 3 months ago

Per standarden er det ikke lov å akseptere både DPoP og Bearer.

Dette kan vi desverre ikke løse i HelseId.Api pakken. Vi må løse det med f.ex. retry logikk, som definert i https://datatracker.ietf.org/doc/html/rfc9449#section-7.2

eller ved at API'ene som tar i bruk dpop må lage egne dpop-endepunkter.