OAuth2 Overview
OAuth2 is an authorization framework to grant limited access to a webservice. Access to the webservice is provided only when the client presents a valid token. This token is often called a bearer token or access token and behaves much like a key card at a hotel. It can grant access to certain resources for a specific amount of time and limits the exposure if the token is compromised.
The process of obtaining a bearer token (interactive or non-interactive) can utlize different means of proving identity (credentials or signed JWT). It just depends on the implementation. Anyway you cut it, QIE has you covered.
Proving Identity
Before given access to an OAuth2 service, some kind of registration process will occur. As a result of the registration, either certificates or credentials are given that will be used to identify the client. Certificates can digitally sign a payload (JsonWebToken or JWT) which will uniquely identify themselves. Credentials can also be submitted to prove identity.
- OAuth2 with JWT: A certificate can create a signed JsonWebToken also known as a JWT. This not only proves the owner of the certificate, but also specifies an expiration and scope of access. This JWT is submitted in order to obrtain a bearer token.
- OAuth2 with Client Credentials: A username and password are used to prove the identity of the client. These credentials are submitted to an authorization server to identify which user needs access and to prove the ownership of that access. Client credentials often have different labels, for example: username/password, clientId/clientSecret, apiKey/sourceSecret. The implementation of how these credentials are submitted can vary widely. QIE provides the flexibility to adapt to any API implementation. More information on this can be found in this KB.
Process of Obtaining a Bearer Token
Although all OAuth2 webservices require a bearer token, the actual process of obtaining a bearer token varies greatly depending on the type of access and the implementation. Non-interactive or backend services are used for automated or batch processing. Interactive or user launched approaches are in the context of a user needing access to the resources during an HTTP session.
- Non-Interactive Backend Services: These services are automated processes that need to obtain a bearer token so they can access another service. In the context of FHIR, these are often referred to as SMART Backend Services. The client will need to prove their identity with the authentication endpoint in order to obtain a bearer token.
- Interactive User Launched Flow: With an interactive launch, an EHR user launches a 3rd party application. The application goes through a series of steps to grant access back to the EHR's FHIR server. This is often called "Authorization Code Flow" or "3-legged OAuth Flow" because there are a series of redirects in the process of verifying the identity of the 3rd party application.
