A whistlestop tour of FHIR API
authentication and authorization
Dunmail Hodkinson
HL7 UK
Authentication
The process of
identifying an individual
Authorization
Giving an individual
access to operations
and resources
FHIR standard
• Does not include security
• Provides guidance and suggestions
• Includes supporting functionality
https://www.hl7.org/fhir/security.html#authentication
https://www.hl7.org/fhir/security.html#binding
PATTERNS
None
FHIR
Client
FHIR
Server
http
Basic
FHIR
Client
FHIR
Server
https
Authorization: Basic
Security
Provider
TLS-MA
FHIR
Client
FHIR
Server
https
X.509 certificate
Security
Provider
Bearer
FHIR
Client
FHIR
Server
trust
Security
Provider
https
Authorization: Bearer
OAuth
‘An open protocol to allow secure
authorization in a simple and standard
way from web, mobile and desktop
applications’
http://oauth.net/
SMART on FHIR
‘Medical apps that integrate into
diverse EHRs at the point of care’
patient/*.read
user/*.*
patient/Observation.write
http://docs.smarthealthit.org/authorization/scopes-and-launch-context/
JSON Web Token (JWT)
‘an open, industry standard RFC 7519 method for representing
claims securely between two parties’
{
iss: 'https://auth.example.net',
sub: 'user@example.net',
nbf: 1463059456166,
exp: 1463064578213,
iat: 1463059366160,
aud: ['https://fhir.example.net'],
jti: '5794b4f6-90bb-41a2-8e11-27ff4adb8880',
}
https://jwt.io/
JWT claims for FHIR
{
…
fhir_scp: [
'*'
],
fhir_act: [
'read:Patient,Observation',
’$getRecord:Patient'
]
}
https://github.com/BlackPearSw/jwt-claims-fhir/blob/master/jwt-claims-fhir.md
SUPPORTING FUNCTIONALITY
Compartments
‘Each resource may belong to one or more logical
compartments. A compartment is a logical
grouping of resources which share a common
property. … [They can] provide a definitional basis
for applying access control to resources quickly.’
[base]/fhir/Patient/123/Condition
https://www.hl7.org/fhir/compartments.html
Contract resource
‘A formal agreement between parties
regarding the conduct of business,
exchange of information or other
matters’
https://www.hl7.org/fhir/contract.html
Consent resource
‘A record of a healthcare consumer’s
privacy policy, which is in accordance with
governing jurisdictional and organization
privacy policies that grant or withhold
consent.’
http://hl7-fhir.github.io/consent.html
Dunmail Hodkinson
dunmail@blackpear.com
@dunmailh

A whistlestop tour of FHIR API authentication and authorization

Editor's Notes

  • #4 FHIR being adopted. Need to consider how we properly secure APIs. Terminology: Authentication vs Authorisation FHIR v2 https://www.hl7.org/fhir/security.html#authentication Authentication: Custom TLS-MA OAuth2 Authorisation: None Custom OAuth2 + OpenID Connect OAuth2 + OpenID (SMART tokens) jwt.io jwt claims for FHIR Apps - complex pattern Underlying support Compartments Contract resource Consent resource
  • #6 Authentication – none Authorisation – none Not recommended in production
  • #7 Example of a custom scheme Authentication: Server trusts client if the credentials (username:password) presented are accepted by the security provider Authorisation: Server allows client to access resources based on custom information provided by the security provider Quick and easy to implement. Can leverage existing authentication infrastructure e.g. LDAP
  • #8 Authentication: Server trusts clients who present valid X.509 certificate Authorisation: Server MAY access Good for B2B Client certificate management at scale can be hard
  • #9 Authentication: Server trusts clients that present a valid token from a trusted security provider Authorisation: Server allows client to access resources based on a claims within the token Good for individual level access OAuth2 - authentication
  • #10 De facto standard for bearer token 2 versions – OAuth, OAuth2 – FHIR recommends OAuth2
  • #11 Designed to allow apps to integrate to an EHR. Oauth2 authentication & access scopes Predates FHIR, so not a clear mapping between scopes and requests. Need custom code to differentiate operations e.g. is $bar a read operation or a write operation?
  • #12  Recommended by GDS Can be used in conjunction with OAuth2 Can be extended by adding additional
  • #13 Authentication: Server trusts clients that present a valid token from a trusted security provider Authorisation: Server allows client to access resources based on a claims within the token Good for individual level access OAuth2 - authentication
  • #15 Resource – not used directly for authentication and authorisation – may be used by an authorisation provider Could be used to record DSA Difficult to model individual patient consent
  • #16 Resource – not used directly for authentication and authorisation – may be used by an authorisation provider Could be used to record DSA Difficult to model individual patient consent
  • #17 Resource – not used directly for authentication and authorisation – may be used by an authorisation provider Could be used to represent individual patient consents