Schritt 1: Registrierung eines SMART Backend Services

Informativ

Die Registrierung eines SMART Backend Services erfolgt per "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants". Siehe Authentifizierung der Clients. Dieser Schritt erfolgt einmal solange der durch den Client verwendete JSON Web Key nicht rotiert werden muss. Entsprechend wird auch für SMART Backend Services die Verwendung von JSON Web Key Sets empfohlen.

Schritt 2: Abruf .well-known/smart-configuration

Informativ

Alle für die automatisierte Parametrisierung eines Clients erforderlichen Angaben zum Abruf eines Access-Tokens können aus dem ".well-known/smart-configuration" Dokument des Ressourcenservers entnommen werden. Siehe Abruf SMART Configuration

Schritt 3: Abruf Access Token

Informativ

SMART Backend Services gelten, wie in der Einleitung beschrieben, als Systeme, die Interaktionen ohne menschliche Anwender durchführen. Diese Interaktionen sind nicht an ein spezifisches Benutzerprofil gekoppelt und erfolgen ohne Authentifizierung über einen Login. Durch die Hinterlegung von Schlüsselinformationen aus Schritt 2 sichert der Ressourcen-Server ein Vertrauensverhältnis zwischen Backend Service und Ressourcen-Server zu. Dies bedeutet, dass ein Client ohne weiteren Zwischenschritt ein Access Token für den Ressourcen-Server am Autorisierungsserver anfragen kann. Dies erfolgt per RFC6749 - Abschnitt 4.4 Client Credentials Grant.

JWT Client Assertions

Bei der Generierung einer Client Assertion entsprechend der Vorgaben aus SMART App Launch - 5.0.5 - Authenticating to the Token endpoint ist zu beachten, dass der "aud"-Parameter die URL des Autorisierungsservers enthält und nicht die des Ressourcenservers. Entsprechend der Vorgaben der Kernspezifikation DARF der "exp" NICHT länger als fünf Minuten gewählt werden (ANF-CON-040). Der Autorisierungsserver MUSS für die sichere Authentifizierung des Clients die JWT Client Assertion validieren, siehe SMART App Launch - 4.1.5.2.1 - Authenticating to the Token endpoint (ANF-CON-041).

Die Client Assertion ist nach der Signierung durch den Client als Teil eines application/x-www-form-urlencoded-Requests an den Token-Endpunkt des Autorisierungsserver zu übermitteln. Für weitere Hinweise siehe SMART App Launch - 5.0.5 - Authenticating to the Token endpoint.

Hinweise zu verwendeten Scopes

Als Teil der Registierung des Clients SOLLTE festgelegt werden, welche Scopes der Client anfragen und verwenden darf. Da wäre des Token-Requests kein Benutzerkontext hergestellt werden kann, SOLLTEN nur "system"-Level Scopes verwendet werden. "Patient"- und "User"-Level Scopes KÖNNEN verwendet werden (ANF-CON-042). Hier bedarf es jedoch einen proprietären Austausch des Kontexts zwischen dem Client und dem Autorisierungsserver. Falls Scopes durch den Client angefragt werden, die nicht durch die Registrierung des Clients abgedeckt sind, MUSS dies durch den Autorisierungsserver abgewiesen werden (ANF-CON-043). Die erteilten Scopes MÜSSEN in der Antwort auf die Token-Annfrage als "scope"-Parameter durch den Autorisierungsserver an den Client übergeben werden (ANF-CON-044).

Beispiel

Request:

POST /token HTTP/1.1 Content-Type: application/x-www-form-urlencoded Host: server.example.com

grant_type=client_credentials& scope=system/*.rs client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer client_assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzM4NCJ9.eyJpc3MiOiJFeGFtcGxlIElzc3VlciIsImlhdCI6bnVsbCwiZXhwIjoxNjQzOTg2OTcwLCJhdWQiOiJodHRwczovL2V4YW1wbGUub3JnL2F1dGgvdG9rZW4iLCJzdWIiOiJUZXN0Q2xpZW50SWQiLCJqdGkiOiI3NmE1ZTA4Ni1lOWE3LTQ0ZmUtOTcyOC03MTIxNjE1YzYyOTEifQ.i_Hzfzuqquc7ouj0-CDxtddvsLxTr5RmcR-hlXYRFmAvxaAg6akf_EL6DAqRVLfW1u-FU9JJs015eTvtugYNNI0QPWdZVHJQ54TVIkVx8jsaf_RvbF3q4DpeiRdEXv1j34k_KrgNRTi6d1Rneem8qmTKIQRiWv1iYeNgENPHnL0SV69Pi7PoXr2s7JWFUO56HqWR0tmPweVm3aS24jeAaRGqISAbTPHuq-R8QVD7fMFqQBR_n6xSMCHUxZHBQDFg2c6leY8WlrwZUz9lJZnX5R76iHylfqZ-kAk38xHpnFtsmbF8YH4EUjYmSGT8SPn0y9RHKFI7LCm9p5DeVPPgYQ

Response:

{
  "token_type": "Bearer",
  "scope": "system/*.rs",
  "expires_in": 3600,
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuZWVkX3BhdGllbnRfYmFubmVyIjp0cnVlLCJzbWFydF9zdHlsZV91cmwiOiJodHRwczovL3NtYXJ0LmFyZ28ucnVuLy9zbWFydC1zdHlsZS5qc29uIiwicGF0aWVudCI6Ijg3YTMzOWQwLThjYWUtNDE4ZS04OWM3LTg2NTFlNmFhYjNjNiIsInRva2VuX3R5cGUiOiJiZWFyZXIiLCJzY29wZSI6ImxhdW5jaC9wYXRpZW50IHBhdGllbnQvT2JzZXJ2YXRpb24ucnMgcGF0aWVudC9QYXRpZW50LnJzIiwiY2xpZW50X2lkIjoiZGVtb19hcHBfd2hhdGV2ZXIiLCJleHBpcmVzX2luIjozNjAwLCJpYXQiOjE2MzM1MzIwMTQsImV4cCI6MTYzMzUzNTYxNH0.PzNw23IZGtBfgpBtbIczthV2hGwanG_eyvthVS8mrG4"
}

Schritt 4: FHIR Restful Interaktion

Informativ

Für die Übermitelung des Token an den Ressourcen-Server, siehe Schritt 5 - FHIR Restful Interaktion.