Einführung

Der OAuth 2.0 Flow ist im Detail abhängig von der konkreten Anwendungsarchitektur. Die Spezifikation OAuth 2.0 for Browser-Based Apps unterscheidet hier drei mögliche Architekturansätze, mit unterschiedlichen Auswirkungen auf den OAuth 2.0 Flow und den damit verknüpften Bedingungen. 

• Die Fälle OAuth 2.0 for Browser-Based Apps - 6.1, OAuth 2.0 for Browser-Based Apps - 6.2 müssen in unserer Betrachtung nicht unterschieden werden.

• Der Fall, dass eine Fachanwendung nur im Browser läuft (OAuth 2.0 for Browser-Based Apps - 6.3) - also eine reine Browseranwendung darstellt - wird nicht als relevanter UseCase für eine Anwendung des Gesundheitswesens mit Bedarf einer Nutzerauthenitisierung betrachtet.

Bei Web-Anwendungen sollten auf Seiten des jeweiligen Fachdienstes die in OAuth 2.0 Security Best Current Practice beschriebenen Sicherheitsaspekte berücksichtigt werden. 

Der Ablauf des OIDC Flow ist prinzipiell identisch mit dem App-zu-App-Flow. 

Terminologie

Erläuterungen zur verwendeten Terminologie sind zentral für alle Flows hier abgelegt.

Vorbedingungen

• Registrierung der Fachanwendung als RP beim Federation Master
• Registrierung des App-Link/Universal-Link für das Authenticator-Modul des IDP auf dem Gerät des Nutzers (auf Adresse des IDP) - oder anfragen über Web.
• Aktueller Signaturschlüssel des Federation Master ist bekannt und vertrauenswürdig bei IDP und Fachdienst eingebracht worden.
• Sektorale IDP ist Teil des TI-Vertrauensraums und beim Federation Master registriert.
• Der Fachdienst besitzt ein Web-Backend welches Anwendungslogik realisiert.

Flow - OIDC

Flow Diagramm

Textuelle Beschreibung der Aktivitäten je Transaktion sowie in den Übergängen

Flow - OAuth 2.0 Flow mit Web-Backend in Fachdienst-Domäne

Der OAuth 2.0 Flow basiert auf der Spezifikation https://tools.ietf.org/id/draft-ietf-oauth-browser-based-apps-07.html#name-browser-based-apps-that-can.

Werden Web-Backend, Authentifizierungsservice und Resourcenserver eines Fachdienst in einer Domäne betrieben, so ist gemäß OAuth 2.0 for Browser-Based Apps - 6.1 OAuth konformes Redirect und das Ausstellen von Authorization-Code nicht notwendig. Für die Kommunikation zwischen Web-Backend und Browser muss ein entsprechend sicheres Pattern verwendet werden (z.B. Http-only cookie, Split Access Token Cookie Pattern), um die Anwendung gegen potentielle Arttacken abzusichern.

Flow Diagramm

Textuelle Beschreibung der Aktivitäten je Transaktion sowie in den Übergängen

Flow - Ermittlung und Auswahl IDP

Die konkrete Umsetzung ist hier Anwendungsspezifisch.
Zum einen kann der Autorisierungsserver die Auswahlliste der IDPs erst bei Eingang eines AUTHORIZATION_REQUEST durch das Web-Backend zur Anzeige beim Nutzer bringen lassen. 

• Alternativ ruft das Web-Frontend beim Autorisierungsserver die Liste aller IDPs ab. Die Ermittlung der registrierten IDPs erfolgt über den Federation-Master. Beim Federation-Master sind die Entity-Statements aller registrierten IDP hinterlegt. Die Bereitstellung der Liste kann über zwei Wege erfolgen:

a) Der Client verwendet das OIDC Federation API. Der Client muss dann aus dem Response die für eine Auswahl notwendigen Informationen extrahieren.

b) Der Federation-Master stellt ein zusätzliches API neben dem Standard-API bereit und liefert hier nur die für eine Auswahl notwendigen Informationen (Name der Organisation/Kasse, Icon, weitere Informationen für Folge-Request zur Ermittlung des vollständigen Entity-Statement).  Die Adresse des API kann z.B. als custom-metadata im Entity-Statement des Federation Master hinterlegt werden.

Flow Diagramm (Abruf der IDP-Liste durch Web-Frontend)

Textuelle Beschreibung der Aktivitäten je Transaktion sowie in den Übergängen

Schnittstellenbeschreibung

Exemplarische Beschreibung des Ablaufs einer Dienstnutzung sowie der Vor- und Nachbedingungen

(0) Abruf der Schlüssel des Federation Master

Der Abruf der Schlüssel des Federation Master erfolgt analog dem App-zu-App Flow (Federation Master)

IDP Liste

Beschreibung zur IDP-Liste ist im App-zu-App Flow (IDP-Liste).

(1)  Authorization Request von Web-Backend zum Authentication Endpunkt (Auth ES) des Autorisierungsserver des Fachdienstes

Die Kommunikation zwischen Web-Frontend und Web-Backend ist anwendungsspezifisch. Das Web-Backend des Fachdienstes sendet einen Request an den Autorisierungsserver des Fachdienstes. Dieser Request ist ebenfalls anwendungsspezifisch. Damit der weitere Ablauf OIDC konform und weitest gehend identisch zum App-zu-App Flow ablaufen kann, muss der Request einigen Festlegungen genügen.

Das Web-Backend sendet ein HTTP-GET an den AS des Fachdienstes.

Die folgenden GET-Parameter werden im query string verwendet:

"digaxy"

VSCHAR

(1 a) Falls der Autorisierungsserver des Fachdienstes das EntityStatement des IDP noch nicht kennt, lädt er dies herunter

Request analog App-zu-App Flow (1a):

(1 b) Der IDP sendet sein EntityStatement zurück

Response analog App-zu-App Flow (1b)

signed_jwks

Die Werte sind analog zu App-zu-App Flow (1-signed_jwks)

(1 c) Der Autorisierungsserver des Fachdienstes ruft das Entity Statement zum IDP beim Federation Master ab

Request analog App-zu-App Flow (1c)

(1 d) Der Federation Master sendet sein EntityStatement über den angefragten sektoralen IDP zurück

Response analog zu App-zu-App Flow (1d)

(2) Der Autorisierungsserver des Fachdienstes sendet ein (Pushed) Authorization Request an den Authentication Endpunkt (Auth ES) des sektoralen IDP

HTTP-POST analog App-zu-App Flow (2)  inclusive TLS Clientauthentisierung.

(2 a) Falls der IDP das EntityStatement des Autorisierungsserver des Fachdienst noch nicht kennt, lädt er dies herunter.

Request analog App-zu-App Flow (2a)

(2 b) Der Autorisierungsserver des Fachdienst sendet sein EntityStatement zurück und der IDP registriert ihn als Client 

Response analog App-zu-App Flow (2b)

signed_jwks

Die Werte sind analog zu App-zu-App Flow (2b-signed_jwks)

(2 c) Abruf des Entity Statement zum Fachdienst beim Federation Master

Request analog App-zu-App Flow (2c)

(2 d) Der Federation Master sendet sein Entity Statement über den Fachdienst zurück

Response analog App-zu-App Flow (2d)

(3) Der Authentication-Endpunkt (Auth EP) des sektoralen IDP antwortet dem AS des Fachdienst mit einer Request URI

Response analog App-zu-App Flow (3)

(4) Der Authorization Server des Fachdienst antwortet dem Frontend mit einem redirect und seiner Request URI

Abweichend vom APP/APP-Flow läuft der Redirect zum Web-Frontend.

Redirect analog App-zu-App Flow (4)

(5) Das Web-Frontend sendet den Authentication Request an die URI des IDP und leitet ihn somit an das Authenticator Modul weiter

HTTP-GET analog App-zu-App Flow (5)

(6) Das Authenticator Modul leitet den Authentication Request an den IDP weiter. (proprietär)

Die Schritte zur Nutzer-Authentifizierung und zur Erstellung des AUTHORIZATION_CODE durch den IDP sind anwendungsspezifisch und werden hier nicht weiter spezifiziert.

(7) Der Authorization-Endpunkt des sektoralen IDP antwortet dem Authenticator Modul mit einem Redirect zum Fachdienst. (proprietär)

Redirect analog App-zu-App Flow (7)

(8) Das Authenticator Modul des IDP ruft über die Redirect-URL den Autorisierungsserver des Fachdienstes auf und übergibt den "AUTHORIZATION_CODE"

Abweichend vom App/App Flow führt das Authenticator-Modul des IDP den Redirect zum Authorization-Server des Fachdienstes aus und übergibt den AUTHORIZATION_CODE. Der Request wird mit einem HTTP-OK quittiert.

HTTP-POST analog App-zu-App Flow (9)

(9) Der Autorisierungsserver reicht den "AUTHORIZATION_CODE" und  den "Code_Verifier" beim Token-Endpunkt des IDP ein.

HTTP POST analog App-zu-App Flow (10) inclusive TLS Clientauthentisierung.

(10) Der Autorisierungsserver erhält vom Token-Endpunkt des IDP einen ID_TOKEN und ACCESS_TOKEN mit den gewünschten Claims, der mit dem öffentlichen Schlüssel aus der Registrierung verschlüsselt ist.

Response analog App-zu-App Flow (11)

(11) Der Autorisierungsserver des Fachdienst reicht das ACCESS_TOKEN und REFRESH_TOKEN an das Web-Backend der Anwendung weiter. 

HTTP-200

• Content-Type=application/json
• Cache-Control=no-store
• Pragma=no-cache

Die JSON-Struktur sieht so aus:

{

"access_token": <ACCESS_TOKEN>, 

"refresh_token": <REFRESH_TOKEN>,

"token_type": "Bearer",

"scope": "e-rezept", 

"expires_in": 300, (Gültigkeit des ACCESS_TOKEN in Sekunden, https://tools.ietf.org/html/rfc6749 section 4.2.2)

}

(12) Kommunikation Web-Frontend, Web-Backend der Anwendung und Fachdienst-API

Das Web-Backend persistiert Access-Token und Refresh-Token. Das Web-Backend benötigt diese für die autorisierte Kommunikation mit dem Fachdienst-API. Die Kommunikation zwischen Web-Frontend und Web-Backend ist implementierungsspezifisch. Access-Token und/oder Refresh-Token werden nicht an das Frontend weitergereicht.

Das Web-Backend verwendet das Access-Token für die Kommunikation mit dem Fachdienst-API. Das Fachdienst-API prüft den Access-Token bevor Anfragen entsprechend quittiert werden.

GET /resource/1 HTTP/1.1
     Host: example.com
     Authorization: Bearer <ACCESS_TOKEN>