Publish Box goes here

Clientauthenticatie

Clientauthenticatie

Clientauthenticatie beantwoordt de vraag: welk geregistreerd systeem van welke zorgaanbieder vraagt een token aan? Zij verleent nog geen toegang tot een FHIR-resource; dat gebeurt pas bij autorisatie.

Benodigde vertrouwensinput

Vóór de tokenaanvraag beschikt het clientsysteem over:

• de organisatie-identificatie van de bronhouder;
• het geregistreerde tokenendpoint en de issuer van de bronhouder;
• de eigen organisatie-identificatie en signing key;
• een clientcertificaat voor mTLS;
• de vertrouwde publieke sleutelregistratie en certificaatstatusvoorziening.

De authorization server haalt de publieke clientkey uit de vertrouwde registratie. Een key uit de assertion zelf of uit een vrije requestparameter vestigt geen vertrouwen.

Twee aanvullende bewijzen

Het tokenendpoint gebruikt twee vormen van clientauthenticatie:

1. mTLS bewijst tijdens de TLS-handshake bezit van de private key bij het aangeboden clientcertificaat en beschermt het volledige tokenverzoek;
2. private_key_jwt bewijst op applicatieniveau bezit van de geregistreerde signing key en bindt de assertion aan clientorganisatie en de authorization-server-issuer.

Het VWS/Twiin-conceptmemo van 13 juli 2026 kiest ervoor de organisatiehandtekening aan de sleutel van het geregistreerde organisatiecertificaat te verbinden. Ook dan hebben mTLS en de applicatiehandtekening een andere functie en worden zij afzonderlijk gecontroleerd. Het precieze landelijke certificaatprofiel en sleutelbeheer zijn nog niet vastgesteld.

Client assertion

De client assertion is een kortlevende, ondertekende JWT:

{
  "iss": "2.16.528.1.1007.3.3.11111111",
  "sub": "2.16.528.1.1007.3.3.11111111",
  "aud": "https://as.example.org",
  "iat": 1784275200,
  "nbf": 1784275200,
  "exp": 1784275320,
  "jti": "unieke-assertionwaarde"
}

Profielregels:

• de handtekening moet geldig zijn onder de geregistreerde publieke clientkey;
• iss en sub moeten beide de geregistreerde organisatie-identificatie van het clientsysteem bevatten;
• aud moet volgens FAPI 2.0 exact de vertrouwde issuer identifier van de authorization server zijn;
• iat en exp moeten aanwezig, actueel en onderling begrensd zijn; een aanwezige nbf mag nog niet in de toekomst liggen;
• jti moet aanwezig, niet leeg en niet eerder gebruikt zijn;
• de assertion mag niet als drager van de RAR worden geïnterpreteerd.

De authorization server moet veilig stoppen bij een onbekende organisatie, onjuiste key, afwijkende audience, ongeldige tijd of replay.

Tokenrequestparameter

private_key_jwt is de naam van de clientauthenticatiemethode. De requestparameter heeft de RFC 7523 jwt-bearer URN als waarde:

client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
client_assertion=[compact JWT]

Een letterlijke waarde private_key_jwt in client_assertion_type is in deze uitwerking ongeldig.

Certificaatstatus

Een geslaagde TLS-handshake toont dat het clientsysteem een private key bezit bij een certificaat onder een vertrouwde keten. De authorization server controleert daarnaast dat de geregistreerde certificaatstatus van de client actueel en aanvaardbaar is. Het clientsysteem voert dezelfde afzonderlijke statuscontrole uit voor het geregistreerde broncertificaat voordat het de bronhandtekening vertrouwt.

Open ontwerpkeuze: de productie-PKI, statusbron, actualiteit en omgang met een niet-beschikbare statusvoorziening moeten nog worden vastgesteld. Een onbekende of niet controleerbare status mag niet stilzwijgend als geldig worden behandeld.

Replay en tijd

Een assertion kan correct ondertekend maar toch oud of herhaald zijn. De authorization server bewaart daarom gebruikte jti-waarden tot na het geldigheidsvenster. Bij horizontale schaal moet deze replayregistratie worden gedeeld tussen alle instanties die dezelfde client assertions accepteren.

Referentie-implementatie: ClientAssertionService gebruikt ES256, maakt assertions met een levensduur van twee minuten, staat maximaal vijf minuten toe en hanteert zestig seconden klokafwijking. Dit zijn concrete, veilige demokeuzes; definitieve productiegrenzen vereisen profielgovernance.

Resultaat

Na geslaagde clientauthenticatie weet de authorization server welke geregistreerde organisatie het tokenverzoek doet. Zij moet daarna nog de gevraagde autorisatie en de tokenendpoint-DPoP-proof controleren voordat zij een access token uitgeeft.