Authentication and Authorization

Generally, the MediKIT APIs use a Bearer token carrying a JWT for authentication and authorization.

Authorization structure

Each server is assigned one or more OAuth clients it can use to authenticate to the MediKIT API. Each client encodes:

• A set of roles associated with the client. The appropriate roles can be agreed with the MediKIT team.
• The tenants (customers) the client may act for. Tenants control which clients can access their data.

Authentication

Servers obtain access tokens using the OAuth 2.0 Client Credentials grant, with the client authenticating via a JWT-based client assertion (private_key_jwt). See RFC 6749 §4.4 and RFC 7523. The .well-known/openid-configuration endpoints for the various environments is available at the following URLs:

• Test: https://www.medikit.nl/auth/realms/dev/.well-known/openid-configuration
• Staging: https://www.medikit.nl/auth/realms/acc/.well-known/openid-configuration
• Production: https://www.medikit.nl/auth/realms/prd/.well-known/openid-configuration

To facilitate the JWT-based client assertion, a certificate associated with the signing key used should be provided during onboarding.

Endpoints

• Test: dev.api.medikit.nl
• Staging: acc.api.medikit.nl
• Production: api.medikit.nl

Tenants and compartmentalization

Practically every request made to the MediKIT API is bound to a tenant. For this purpose, the MediKIT API exposes a FHIR server for each tenant. This means that each request is made to endpoints like this:

GET <BASE_URL>/<TENANT_ID>/fhir/<RESOURCE_TYPE>

Furthermore, for any patient-bound queries, the request needs to also encode the patient in question through FHIR Compartments. This means that requests for a Patients MedicationRequest resources, for example, can be made like this:

GET <BASE_URL>/<TENANT_ID>/fhir/Patient/<PATIENT_ID>/MedicationRequest