Register the backend client with the FHIR authorization server by providing the client's public JWKS (JSON Web Key Set) URL or inline JWKS during client registration
At runtime, construct a JWT client assertion with claims: iss and sub set to the client_id, aud set to the token endpoint URL, jti as a unique nonce, and exp set to no more than 5 minutes in the future
Sign the JWT using the client's private RSA or EC key corresponding to the registered public key
POST to the token endpoint with grant_type=client_credentials, client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer, client_assertion=<signed JWT>, and scope=system/*.read (or specific resource scopes)
Extract the access_token from the token response and include it as a Bearer token in the Authorization header on all subsequent FHIR API requests
Known gotchas
The jti claim must be unique per token request and the authorization server typically rejects reused jti values within the token's validity window to prevent replay attacks — use a UUID or cryptographically random value
Some FHIR servers require the JWKS to be retrievable at the registered URL at the time of each token request rather than caching the keys at registration; ensure the JWKS endpoint remains accessible and returns the current public key
System-level scopes use the system/ prefix (e.g., system/Patient.read) rather than patient/ or user/ — using the wrong scope prefix results in a scope not granted error even if the client is authorized
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp