Publish Box goes here

Autorisatie en access token

Autorisatie en access token

Clientauthenticatie stelt vast welke organisatie een token aanvraagt. Autorisatie beantwoordt een andere vraag: tot welke resource van welke organisatie wordt voor welk doel toegang gevraagd en verleend?

Rich Authorization Request

Het clientsysteem stuurt de autorisatiedetails als losse authorization_details-parameter:

{
  "type": "nl-gis-v1",
  "purpose_of_use": "http://terminology.hl7.org/CodeSystem/v3-ActReason|TREAT",
  "locations": [
    "https://fhir.example.org/fhir/bgz"
  ],
  "locations_organization_id": "2.16.528.1.1007.3.3.22222222"
}

De velden hebben elk een eigen betekenis:

Resourcebinding

Deze uitwerking vereist één aangevraagde locatie en de volgende gelijkheid:

tokenrequest resource
  == authorization_details.locations[0]
  == access token aud
  == uiteindelijke FHIR-request-URI

Daarnaast moet locations_organization_id overeenkomen met de doelorganisatie waaruit het endpoint via vertrouwde discovery is afgeleid.

Profielregel: de authorization server mag geen token uitgeven als RAR-type, gebruiksdoel, locatie, doelorganisatie en resource niet gezamenlijk door haar beleid worden geaccepteerd.

Referentiekeuze: nl-gis-v1, precies één locatie en alleen TREAT zijn de huidige, bewust kleine policy van de code. Meer gebruiksdoelen of locaties vereisen expliciete semantiek en governance; zij zijn niet automatisch verboden door OAuth of RAR zelf.

Integriteit en acceptatie

De RAR is geen claim in de client assertion. De mTLS-verbinding beschermt de losse formparameter tijdens het tokenverzoek. De authorization server:

1. parseert de aangevraagde details;
2. past haar eigen autorisatiebeleid toe;
3. weigert ongeldige of niet-toegestane details;
4. neemt alleen de geaccepteerde details op in het getekende access token.

Het clientsysteem mag daarom niet aannemen dat de uitgegeven autorisatie gelijk is aan de aanvraag. Het controleert de getekende uitkomst.

Access-tokenclaims

Een geaccepteerd token bevat in deze profieluitwerking:

{
  "iss": "https://as.example.org",
  "sub": "2.16.528.1.1007.3.3.11111111",
  "client_id": "2.16.528.1.1007.3.3.11111111",
  "aud": ["https://fhir.example.org/fhir/bgz"],
  "iat": 1784275200,
  "exp": 1784275500,
  "jti": "unieke-tokenwaarde",
  "authorization_details": [{
    "type": "nl-gis-v1",
    "purpose_of_use": "http://terminology.hl7.org/CodeSystem/v3-ActReason|TREAT",
    "locations": ["https://fhir.example.org/fhir/bgz"],
    "locations_organization_id": "2.16.528.1.1007.3.3.22222222"
  }],
  "cnf": {
    "jkt": "publieke-JWK-thumbprint"
  }
}

cnf.jkt bindt het token aan de publieke DPoP-key. De betekenis daarvan staat op DPoP en transport.

Controle door het clientsysteem

Vóór de resource-aanroep controleert het clientsysteem:

1. ES256-handtekening via de JWKS uit de vertrouwde bronhouderregistratie;
2. iss tegen de geregistreerde issuer;
3. sub en client_id tegen de eigen organisatie-identificatie;
4. aud tegen de exacte gekozen resource;
5. iat en exp;
6. aanwezigheid, structuur en beleid van authorization_details;
7. doelorganisatie, gebruiksdoel en location;
8. aanwezigheid van cnf.jkt.

Profielregel: bij een ontbrekende of tegenstrijdige claim stopt het clientsysteem vóór de FHIR-aanroep.

Deze client-side inspectie is een bewuste Nederlandse profieltoevoeging en staat op gespannen voet met OAuth-profielen waarin het access token voor de client opaque blijft. De profielpagina beschrijft deze keuze expliciet.

Controle door de resource server

De resource server vertrouwt niet op de eerdere clientcontrole. Zij valideert het token opnieuw tegen haar eigen issuerkey en verwacht dezelfde client, audience, doelorganisatie, location en purpose. Daarna controleert zij de requestspecifieke DPoP-proof.

Ontbrekende autorisatiedetails, afwijkende audience, ander doel-URA, verlopen token, onbetrouwbare signing key of ontbrekende cnf.jkt leidt tot een veilige stop.