Zorgaanbiederauthenticatie en -autorisatie
0.1.0 - prototype

Publish Box goes here

DPoP en transport

DPoP en transport

mTLS en DPoP worden beide gebruikt omdat zij verschillende aanvallen afdekken. mTLS beveiligt een verbinding tussen twee TLS-peers. DPoP bindt een access token en een HTTP-request aan een clientgegenereerde applicatiesleutel.

Verdeling van verantwoordelijkheden

Mechanisme Bindt Controle Belangrijkste beperking
TLS-servervalidatie hostname aan servercertificaat en vertrouwde keten clientsysteem bij ieder endpoint bewijst zonder registratie niet welke zorgaanbieder bij het endpoint hoort
mTLS-clientauthenticatie verbinding aan bezit van clientcertificaatsleutel token- en resource server beschrijft geen autorisatie en bindt niet zelfstandig het access token
DPoP-tokenbinding access token aan publieke DPoP-key via cnf.jkt clientsysteem en resource server versleutelt het kanaal niet
DPoP-requestbinding proof aan methode, URI, tijd en jti authorization of resource server vestigt geen organisatietrust
DPoP-tokenhash resourceproof aan exact compact access token via ath resource server beschermt de FHIR-payload niet buiten TLS

mTLS

De TLS-laag:

  • versleutelt request en response;
  • valideert servercertificaatketen en hostname;
  • laat de server bezit van een vertrouwde clientcertificaatsleutel controleren;
  • beschermt de losse RAR tijdens de tokenaanvraag;
  • beschermt het access token en de FHIR-payload tijdens transport.

Profielregel: token- en resourceverkeer gebruikt wederzijds geauthentiseerde TLS. Applicatieclaims vervangen de TLS-handshake niet en mTLS vervangt organisatieregistratie, RAR, tokenhandtekening of DPoP evenmin.

Tokenendpoint-proof

Het clientsysteem maakt voor de tokenaanvraag een nieuwe DPoP-proof. De ondertekende JWT bevat:

  • typ=dpop+jwt;
  • een ondersteund algoritme en de publieke JWK in de header;
  • htm=POST;
  • htu voor het exacte tokenendpoint;
  • actuele iat;
  • unieke jti.

De authorization server:

  1. controleert type, algoritme en publieke key;
  2. valideert de proofhandtekening;
  3. vergelijkt htm en genormaliseerde htu;
  4. controleert tijd en replay;
  5. neemt de JWK-thumbprint als cnf.jkt op in het access token.

Resourceproof

Voor iedere FHIR-aanroep maakt het clientsysteem een nieuwe proof met dezelfde DPoP-key. Naast htm, htu, iat en jti bevat deze:

ath = base64url(SHA-256(compact access token))

De resource server controleert:

  • dat de proofkey overeenkomt met cnf.jkt;
  • dat htm de werkelijke HTTP-methode bevat;
  • dat htu de exacte resource-URI bevat;
  • dat ath bij het ontvangen access token hoort;
  • dat iat actueel is;
  • dat jti niet eerder is gebruikt.

Authorization-schema

Een DPoP-gebonden token wordt verzonden als:

Authorization: DPoP [access token]
DPoP: [requestspecifieke proof]

Een Bearer-downgrade is niet toegestaan:

Authorization: Bearer [access token]

Profielregel: de resource server weigert een DPoP-gebonden token dat via het Bearer-schema wordt aangeboden of waarvan proof, key, requestbinding of tokenhash niet klopt.

URI-normalisatie

DPoP vergelijkt de genormaliseerde request-URI. De referentie-implementatie normaliseert scheme en hostname naar lowercase, verwijdert de standaard HTTPS-poort 443, behoudt het pad en laat query en fragment buiten de htu. Clientsysteem en controlerende server moeten dezelfde RFC 9449-semantiek hanteren om zowel mismatches als onbedoeld brede binding te voorkomen.

Replay en schaal

Client assertions en DPoP-proofs gebruiken gescheiden replay-namespaces. Een jti wordt minimaal tot na het relevante geldigheidsvenster bewaard.

Open ontwerpkeuze: productie vereist een gedeelde replayvoorziening wanneer meerdere instanties dezelfde assertions of proofs accepteren. Beschikbaarheid van deze voorziening mag niet leiden tot stilzwijgend uitschakelen van replaycontrole.

Referentie-implementatie: de demo gebruikt ES256, een maximale DPoP-proofleeftijd van vijf minuten, zestig seconden toekomstige klokafwijking en in-memory replaystores. De lokale CA en certificaten maken echte mTLS testbaar, maar zijn geen productie-PKI.