Implementation Guide
Health Device Data Transfer
Version 0.1.0 - ballot

Specification of health data transfer from devices to DiGA (§ 374a SGB V)

Pushed Authorization Request Endpoint

Seiteninhalt:

Introduction

This document describes the Pushed Authorization Request (PAR) endpoint of the OAuth 2.0 Authorization Server. The PAR endpoint allows a DiGA to send an authorization request directly to the OAuth2 Authorization Server backend before user consent is collected by the Device Data Recorder. By doing so, sensitive request parameters are not exposed to the user agent, URL length limitations are avoided and the DiGA is authenticated.

The PAR endpoint is a backend-to-backend endpoint and requires client authentication using Mutual-TLS.

Endpoint

Note: There is no strict definition of the PAR endpoint URL in RFC 9126.
The URL below is a common convention. Device Data Recorder manufacturers MAY choose a different URL structure as long as it is properly documented in the OAuth 2.0 Authorization Server Metadata.

   
Endpoint /par
HTTP Method POST
Description Allows a DiGA (OAuth client) to register an authorization request with the OAuth2 Authorization Server. Returns a request_uri that the DiGA later uses when redirecting the patient to the /authorize endpoint.
Authentication Mutual-TLS Client Authentication (see RFC 8705), using tls_client_auth. The Authorization Server MUST validate the client certificate against the DiGA’s registration in the DiGA-VZ.
Returned Objects JSON object containing request_uri and expires_in.
Specifications • MUST comply with RFC 9126.
• The Authorization Server MUST require PAR for all authorization flows (require_pushed_authorization_requests = true).
• MUST use PKCE (RFC 7636).
• MUST strictly validate redirect_uri and scope parameters against the DiGA-VZ registration.
• MUST NOT support the request parameter.
• MUST NOT support JWT-Secured Authorization Requests (RFC 9101).
• MUST return a JSON object containing request_uri and expires_in.
• Interaction with the patient MUST NOT occur at this endpoint (backend-only).
• MUST accept the following parameters in the request body:
 • client_id
 • scope
 • code_challenge
 • code_challenge_method=S256
 • redirect_uri
 • state
 • response_type=code
Error codes 400 (Invalid request)
401 (Unauthorized – client authentication failed)
403 (Forbidden – client not authorized or scope invalid)
500 (Internal Server Error)

Example

Request:

curl -X POST "https://himi.example.com/par" \
  --cert client-cert.pem --key client-key.pem \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "client_id=urn:diga:bfarm:12345" \
  -d "scope=patient/Observation.rs?code:in=https://gematik.de/fhir/hddt/ValueSet/hddt-miv-blood-glucose-measurement" \
  -d "code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM" \
  -d "code_challenge_method=S256" \
  -d "redirect_uri=https%3A%2F%2Fdiga.example.com%2Fcallback" \
  -d "state=af0ifjsldkj" \
  -d "response_type=code"

Response:

{
  "request_uri": "urn:uuid:a1b2c3d4-5678-90ab-cdef-111213141516",
  "expires_in": 90
}