...
EPJ oppretter en LaunchContext som tildeles en unik identifikator og assosieres med client_id for SMART-applikasjonen. Konteksten består av:
Parametere | ||||||||
|---|---|---|---|---|---|---|---|---|
patient |
| Den logiske logiske ressursidentifikatoren for pasienten | ||||||
practitioner |
| Den logiske ressursidentifikatoren for helsepersonellet som benytter applikasjonen | ||||||
encounter |
| Den logiske ressursidentifikatoren for konsultasjonen | ||||||
...
I praksis er dette en URL til webapplikasjonen. Eksempel: Location: https://app/launch?iss=https%3A%2F%2Fehr%2Ffhir&launch=xyz1
Parametere | ||||||||
|---|---|---|---|---|---|---|---|---|
iss |
| Identifiserer EPJens FHIR endepunkt. Web-applikasjonen benytter dette endepunktet for å skaffe ytterligere detaljer EPJen, inkludert URLen til autorisasjonserveren | ||||||
launch |
| Ikke-transparent identifikator for denne spesifikke oppstartsekvensen. Dette parameteret skal kommuniseres tilbake til EPJen på autorisasjonstidspunktet og legges ved som et launch-parameter (se eksempel ovenfor). | ||||||
...
Applikasjonen skal deretter gjøre en forespørsel mot authorize endepunktet med følgende parametere:
Parametere | ||||||||
|---|---|---|---|---|---|---|---|---|
response_type |
| Fiksert verdi code. | ||||||
client_id |
| Klientens identifikator. | ||||||
redirect_uri |
| Må samsvare med en av de forhåndsregistrerte redirect URLene for klienten. | ||||||
launch |
| Må samsvare med den mottatte launch-parameteren fra EPJ. | ||||||
scope |
| Applikasjonen angir ved hjelp av parameteren scope hvilken aksess den trenger til helsedata. Dette inkluderer kliniske scope som patient/*.read, openid, fhirUser, samt et launch scope som indikerer at applikasjonen ønsker den allerede etablerte launch-konteksten fra EPJen. | ||||||
state |
| Ikke-transparent verdi satt av klienten for å opprettholde tilstanden mellom forespørsel og responsen. Autorisasjonsserveren inkluderer verdien når den dirigerer nettleseren tilbake til klienten. Parameteren skal benyttes for å forhindre cross-site request forgery og session fixation attacks. | ||||||
aud |
| URL til EPJen sin ressursserver (FHIR-endepunkt). Denne parameteren skal motvirke lekkasje av genuine bearer tokens til en falsk ressursserver. I kontekst av gjeldende bruksscenario skal verdien i aud parameteren være den samme som var satt i iss parameteren. | ||||||
...
Autorisasjonen avgjøres av EPJens autorisasjonsserver som potensielt kan kreve at sluttbrukeren samtykker til autorisasjonen. Autorisasjonsserveren håndhever tilgangsregler basert på lokale tilgangsregler og ev. input fra sluttbruker. EPJen avgjør til slutt om applikasjonen skal tillates eller nektes tilgang. Avgjørelsen kommuniseres tilbake til applikasjonen ved at EPJens autorisasjonsserver godkjenner forespørselen og returnerer en autorisasjonskode, eller nekter tilgang og returner en feilkode/-respons, se seksjon 4.1.2.1 i RFC6749. Autorisasjonskoder har kort levetid, vanligvis utløper de i løpet av ett minutt. Koden sendes til applikasjonen når EPJens autorisasjonsserver navigerer til applikasjonens redirect_uri med følgende parametere:
Parametere | ||||||||
|---|---|---|---|---|---|---|---|---|
code |
| Autorisasjonskoden generert av autorisasjonsserveren. Autorisasjonskoden skal utløpe kort tid etter at den er utstedt for å begrense risikoen for lekkasjer | ||||||
state |
| Eksakt verdi slik den var mottatt fra klienten | ||||||
...
For såkalte public apps er autentisering ikke mulig siden klienten mangler en secret og kan derfor ikke bevise sin identitet når den utfører et kall. Ende-til-ende systemet kan fortsatt være sikkert siden klienten aksesseres fra et kjent HTTPS beskyttet endepunkt håndhevet av redirect_uri parameteret i konfigurasjonen. For såkalte confidential apps er det påkrevet å sette en Authorization header som benytter HTTP Basic authentication, brukernavnet vil være applikasjonens client_id og passordet er applikasjonens client_secret, se eksempel.
Parametere | ||||||||
|---|---|---|---|---|---|---|---|---|
grant_type |
| Fiksert verdi: authorization_code | ||||||
code |
| Autorisasjonskoden applikasjonen mottok fra autorisasjonsserveren sitt authorization-endepunkt | ||||||
redirect_uri |
| Den samme redirect_uri som ble benyttet i den initiale autorisasjonsforespørslen | ||||||
client_id |
| Påkrevet for public apps, utelates for confidential apps | ||||||
EPJens autorisasjonsserver skal returnere et JSON-objekt som inkluderer et tilgangstoken eller en beskjed som indikerer at tilgangsforespørslen ikke ble godkjent. JSON-strukturen inkluderer følgende parametere:
Parametere | ||||||||
|---|---|---|---|---|---|---|---|---|
access_token |
| Tilgangstoken utstedt av autorisasjonsserveren | ||||||
token_type |
| Fiksert verdi: bearer | ||||||
expires_in |
| Tilgangstokenet sin levetid i sekunder, etter dette vil tilgangstokenet ikke bli akseptert av ressursserveren | ||||||
scope |
| Aksesstilgang som er autorisert, legg merke til at dette kan være forskjellig fra det som applikasjonen initialt ba om | ||||||
id_token |
| Dersom forespurt inneholder informasjon om pålogget bruker | ||||||
refresh_token |
| Et token som kan benyttes til å forespørre autorisasjonsserveren om et nytt tilgangstoken med det samme nivået eller subsett av den opprinnelige autorisasjonstildelingen | ||||||
...