Single Sign-on Through OAuth2
Single sign-on (SSO) adds security and convenience to authentication flow. With SSO, users sign in with one account to open access to a variety of web/software applications, company resources, and domain-joined devices.
It’s neither a protocol nor a specification. Instead, it’s more of a high-level authentication/authorization concept in which a user can log into multiple services using the same credentials.
The main benefit of using SSO is that users have only a single account credential to remember to get access to multiple services.
Single Sign-on and OAuth2 Configuration
Below flowchart helps in deciding which SSO method is appropriate for a situation.
Choosing SSO Method “Reference”
Here we will discuss how a SMART on FHIR application leverage OAuth2 to implement SSO.
SMART on FHIR and OAuth2
OAuth is an authorization protocol that allows users to selectively decide which services can do what with user’s data. A well-known example is that of Spotify app/service allowing its user to sign-in using the Facebook account. In this flow a user allows Spotify to use his/her data from the Facebook account. Though the data access is limited and shared on the user’s consent.
Now, as SMART on FHIR system is a healthcare IT system that has implemented the SMART on FHIR specifications, including profiled version of FHIR, OAuth2, and OpenID Connect; the key function of OAuth2 here is to enable an end-user data, e.g. patient/clinician, to approve a third-party app(SMART app) to have access to specific set of user’s data that resides in an EHR system.
To allow apps to run across varied security environment, SMART on FHIR specifies rules about how apps would obtain authorization tokens. These auth tokens (obtained via OAuth2) are used in every REST API call for data retrieval.
At Technosoft, we have implemented OAuth2 for many of our clients and we have extensive experience with SMART on FHIR apps. At Technosoft, we have dealt with both types of launch sequences that SMART on FHIR supports EHR launch and Standalone launch, an OAuth2 server is configured for data access delegation. Let’s discuss both one by one.
EHR Launch Sequence
Please see content as published officially by HL7 “Reference”
- In this flow, a user (patient/clinician) has established an EHR session, which means the user logged into an EHR system and decided to launch a third-party app (SMART app) from within the EHR.
- EHR initiates launch sequence by opening a new browser instance or iframe pointing to the app’s registered launch URL and some context.
- Once the app is loaded it query the issuer’s /metadata/ endpoint to find out OAuth authorize and token endpoints.
- After getting authorized, the access token is shared by the auth server.
This access token is then used by Technosoft’s customers to retrieve data from the Hospital’s FHIR Servers.
Standalone launch sequence
- In this flow, the user selects an app from outside EHR e.g. by tapping an app icon on the mobile home screen.
- The app is configured and has information about OAuth authorize and token endpoints URL.
- It then declares its launch context requirements by adding scopes in request to EHR’s auth server. For example, if the app needs patient context, the “launch/patient” scope is added in a request for the auth server to provide the end-user with a patient selection widget.
Technosoft has implemented OAuth solutions with Java/J2EE, Python, .Net and Frontend Technologies.
SMART on FHIR application inherently implements SSO since SMART on FHIR specifications enforce authorization via OAuth2 web standard, and as mentioned earlier OAuth2 is one of the multiple methods available to implement the SSO concept.