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.
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.
Erläuterungen zur verwendeten Terminologie sind zentral für alle Flows hier abgelegt.
Schritt | Beschreibung | |
---|---|---|
0 |
| |
1 | Abweichend vom APP/APP-Flow kommt der Request vom Web-Backend der Anwendung und nicht von einem Anwendungsfrontend (App) | |
1-a | Schnittstellendetails analog App-zu-App Flow (1a) | |
1-b | Schnittstellendetails analog App-zu-App Flow (1b) | |
1-c | Schnittstellendetails analog App-zu-App Flow (1c) | |
1-d | Schnittstellendetails analog App-zu-App Flow (1d) | |
2 | Schnittstellendetails analog App-zu-App Flow (2) | |
2-a | Schnittstellendetails analog App-zu-App Flow (2a) | |
2-b | Schnittstellendetails analog App-zu-App Flow (2b) | |
2-c | Schnittstellendetails analog App-zu-App Flow (2c) | |
2-d | Schnittstellendetails analog App-zu-App Flow (2d) | |
3 | Schnittstellendetails analog App-zu-App Flow (3) | |
4 | Abweichend vom APP/APP-Flow läuft der Redirect über das Web-Backend zum Web-Frontend. Schnittstellendetails analog App-zu-App Flow (4) | |
5 | Schnittstellendetails analog App-zu-App Flow (5) | |
6 | Schnittstellendetails analog App-zu-App Flow (6) | |
6-a | Schnittstellendetails analog App-zu-App Flow (6a) | |
6-b | Schnittstellendetails analog App-zu-App Flow (6b) | |
7 | Schnittstellendetails analog App-zu-App Flow (7) | |
8 | Abweichend vom APP/APP Flow führt das Authenticator Modul des IDP den Redirect zum Authorization-Service des Fachdienst aus und übergibt den "AUTHORIZATION_CODE". Schnittstellendetails analog App-zu-App Flow (9) | |
9 | Schnittstellendetails analog App-zu-App Flow (10) | |
10 | Schnittstellendetails analog App-zu-App Flow (11) | |
11 | Der Autorisierungsserver des Fachdienst reicht ACCESS_TOKEN und REFRESH_TOKEN an das Web-Backend der Anwendung weiter. Diese liegen zu keiner Zeit im Browser des Nutzers. | |
12 | Der Access-Token (Refresh-Token) wird im Web-Backend der Anwendung persistiert. Die Kommunikation zwischen Web-Frontend und Web-Backend ist implementierungsspezifisch. |
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.
Schritt | Funktion | Beschreibung | Standard | |
---|---|---|---|---|
A | Die Kommunikation zwischen Web-Frontend (Browser) und Web-Backend ist implementierungsspezifisch und muss den Standards für Web-Anwendungen genügen. | |||
B |
| Das Web-Backend erzeugt einen Request gegen den Authorization-Service des Fachdienstes. Dieser Request kann anwendungsspezifisch sein und muss nicht zwingend ein Standard-konformer Authorization-Request sein. Das Erzeugen eines Codeverifier und einer Codechallenge ist nicht notwendig, da es sich hier um eine gemeinsame Domäne handelt, bestehend aus Web-Backend, Authorization-Service und Fachdienst-API. | - | |
C |
| Der Authorization-Service stellt dem Web-Backend ein Access-Token aus, welches dieser für die sichere Kommunikation des Fachdienstes verwendet. |
| |
D |
| Das Web-Backend speichert sich das Access-Token für folgende Zugriffe auf Services des Fachdienst (Fachdienst-API) | - | |
E | Datenanfragen und -aufbereitung in der Kommunikation zwischen Web-Frontend (Browser) und Web-Backend ist implementierungsspezifisch und muss den Standards für Web-Anwendungen genügen. | |||
F |
| Datenanfragen des Web-Backend an das Fachdienst-API müssen das Access-Token enthalten. |
| |
G |
| Der Fachdienst prüft den Access-Token in Datenanfragen des Web-Backend gegen den Authorization-Service und stellt die Daten bereit. |
|
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.
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.
Schritt | Beschreibung | Standard |
---|---|---|
1 | Anwenderaktion am Web-Frontend der Anwendung zur Auswahl eines IDP | |
2 | Redirect des Web-Backend zum Authorization-Service des Fachdienstes zur Bereitstellung der Auswahl | |
3 | Anfrage des Authorization-Service des Fachdienstes am Federation Master nach Liste der in der Föderation registrierten IDPs |
|
4 | Rückantwort des Federation Master mit der signierten Liste der in der Föderation registrierten IDPs | |
5 | Signaturprüfung der Liste und Darstellung der verfügbaren IDP am Web-Frontend des Fachdienstes | |
6 | Übertragung des durch den Nutzer am Web-Frontend des Fachdienstes ausgewählten IDP (aus der Liste der verfügbaren IDPs) | |
7 | Response auf den Redirect-Aufruf mit den Informationen zum ausgewählten IDP | |
8 | Visualisierung des ausgewählten IDP im Web-Frontend der Anwendung |
Exemplarische Beschreibung des Ablaufs einer Dienstnutzung sowie der Vor- und Nachbedingungen
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).
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:
Name | Werte | Beispiel | Anmerkungen |
---|---|---|---|
client_id | VSCHAR | "digaxy" | kein ";" und kein "┼" (definiert gem. Unicode U+253C (9532)), kein Leerzeichen |
state | VSCHAR | af0ifjsldkj | optional |
redirect_uri | URL | "https://Fachdienst007.de" | Adresse des Fachdienst weil da soll der ACCESS_TOKEN am Ende landen. |
code_challenge | Hash über code_verifier | K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U | PKCE optional weil Kommunikation innerhalb der Anwendung und nichts zum Browser fließt oder Redirects folgt. |
code_challenge_method | S256 | <- | PKCE optional, siehe oben |
response_type | code | <- | CODE Flow optional wenn andere Mechanismen die Verbindung schützen |
scope | "e-rezept" | <- | anwendungsspezifisch zu definieren kein open-id |
weiterere Claims | weitere claims können vereinbart werden | ||
idp_iss | URL | "https://idp4711.de" | nicht Standard Parameter iss URL des IDP den der Nutzer für die Authentisierung ausgewählt hat. optional - nötig wenn Auswahl des IDP im Frontend passiert. |
Request analog App-zu-App Flow (1a):
Response analog App-zu-App Flow (1b)
Die Werte sind analog zu App-zu-App Flow (1-signed_jwks)
Request analog App-zu-App Flow (1c)
Response analog zu App-zu-App Flow (1d)
HTTP-POST analog App-zu-App Flow (2) inclusive TLS Clientauthentisierung.
Request analog App-zu-App Flow (2a)
Response analog App-zu-App Flow (2b)
Die Werte sind analog zu App-zu-App Flow (2b-signed_jwks)
Request analog App-zu-App Flow (2c)
Response analog App-zu-App Flow (2d)
Response analog App-zu-App Flow (3)
Abweichend vom APP/APP-Flow läuft der Redirect zum Web-Frontend.
Redirect analog App-zu-App Flow (4)
HTTP-GET analog App-zu-App Flow (5)
Die Schritte zur Nutzer-Authentifizierung und zur Erstellung des AUTHORIZATION_CODE durch den IDP sind anwendungsspezifisch und werden hier nicht weiter spezifiziert.
Redirect analog App-zu-App Flow (7)
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)
HTTP POST analog App-zu-App Flow (10) inclusive TLS Clientauthentisierung.
Response analog App-zu-App Flow (11)
HTTP-200
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)
}
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>