Koppelmij Implementation Guide - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
2a en 2b
Vergelijking optie 2a en 2b
Gemeenschappelijke basis
Beide opties gebruiken het PGO als SMART on FHIR authorization server en lossen hetzelfde probleem op: veilige browser authenticatie tijdens het launch proces zonder extra login stappen voor de gebruiker.
Optie 2a: PGO Token Exchange
Kern concept: Het PGO voert de Token Exchange uit namens de module
Werkwijze:
- Module doet standaard SMART on FHIR flow met PGO
- PGO voert Token Exchange uit tijdens de
/token
stap
- PGO stuurt module's JWT assertion naar DVA als actor_token
- DVA genereert delegation token en stuurt terug naar PGO
- PGO geeft finale delegation token aan module
- Token response bevat
aud
veld met DVA FHIR URL
Voordelen:
- Module hoeft Token Exchange niet te implementeren
- Eenvoudiger voor module ontwikkelaars
- PGO heeft volledige controle over delegation proces
Optie 2b: Module Token Exchange
Kern concept: De module voert zelf de Token Exchange uit
Werkwijze:
- Module doet standaard SMART on FHIR flow met PGO
- PGO geeft tijdelijk token (5 minuten geldig)
- Module voert zelf Token Exchange uit bij DVA
- Module gebruikt tijdelijk token als subject_token
- DVA genereert delegation token direct voor module
- Geen
aud
veld in PGO response, wel Token Exchange endpoint info
Voordelen:
- Module heeft volledige controle over timing
- Geen delegatie van gevoelige tokens via PGO
- Flexibiliteit in Token Exchange uitvoering
- Kortere token levensduur verhoogt beveiliging
Belangrijkste verschillen
Aspect |
Optie 2a |
Optie 2b |
Token Exchange locatie |
PGO voert uit |
Module voert uit |
PGO token response |
Finale delegation token + aud veld |
Tijdelijk token + endpoint info |
Module complexiteit |
Lager |
Hoger |
Token levensduur |
Standaard (bijv. 1 uur) |
Tijdelijk token: 5 minuten |
Controle |
PGO heeft controle |
Module heeft controle |
Delegatie risico |
PGO handelt gevoelige tokens |
Directe module-DVA communicatie |
Compliance beoordeling
Optie 2b is meer compliant om de volgende redenen:
1. RFC 8693 Token Exchange compliance
- Optie 2b: Module voert Token Exchange direct uit met DVA - dit is de bedoelde werking van RFC 8693
- Optie 2a: PGO handelt namens module, wat een extra delegatielaag toevoegt
2. SMART on FHIR specificatie
- Optie 2b: Gebruikt standaard SMART response zonder non-standaard
aud
veld
- Optie 2a: Voegt custom
aud
veld toe buiten SMART/OIDC specificaties
3. Security best practices
- Optie 2b: Minimale token levensduur (5 min) en directe client-server communicatie
- Optie 2a: Langere token levensduur en extra tussenpartij (PGO)
4. Principe van least privilege
- Optie 2b: Module krijgt alleen wat nodig is voor Token Exchange
- Optie 2a: PGO krijgt volledige toegang tot module's authenticatie context
Aanbeveling
Optie 2b wordt aanbevolen vanwege:
- ✅ Betere compliance met RFC 8693 en SMART on FHIR
- ✅ Hogere beveiliging door korte token levensduur
- ✅ Geen custom velden buiten standaarden
- ✅ Directe authenticatie relatie tussen module en DVA
- ✅ Minder delegatie risico's
Nadeel: Hogere implementatie complexiteit voor modules, maar dit weegt niet op tegen de compliance en security voordelen.