SMART on FHIR: Role of Tokens in Clinical Interoperability

SMART on FHIR is transforming how healthcare systems share and secure data. It combines the FHIR standard for structuring clinical data with OAuth 2.0 and OpenID Connect to ensure secure access. Here's why it matters:

With nearly 90% of U.S. hospitals using APIs for patient data and over two-thirds employing FHIR, this framework is becoming a standard for secure clinical interoperability. By addressing risks like token leakage and enforcing strong security practices, SMART on FHIR ensures safer, more efficient healthcare data exchange.

#2: SMART Access Token Format -- A Guided Walk Through FHIR

sbb-itb-535baee

How Token-Based Authentication Works in SMART on FHIR

When a healthcare app needs to access EHR data through SMART on FHIR, it must first prove its identity. This is done using token-based authentication, where the app requests an access token from the EHR's authorization server. Think of tokens as temporary digital keys that grant specific permissions without exposing sensitive user credentials ^[4][12]. This system ensures secure, real-time access to patient records during clinical workflows, supporting interoperability by allowing only validated apps to handle sensitive EHR data.

The authentication process uses two main methods: symmetric and asymmetric. Each has its own characteristics, but the SMART standard strongly leans toward one for better security.

Symmetric Authentication with Shared Secrets

Symmetric authentication works a lot like a password system. When an app registers with an EHR, it gets a client_id (a public identifier) and a client_secret (a private password). To request an access token, the app sends these credentials to the authorization server using HTTP Basic Authentication. This involves an Authorization header with the Base64-encoded combination of client_id:client_secret ^[9].

If the server validates these credentials, it issues an access token. This token is usually valid for about an hour and includes "scopes" that define the app's access level, like patient/*.read for read-only access to patient data ^[10][4].

While symmetric authentication is straightforward, it has a major security flaw: the client_secret must be sent over the network with every token request. Even though the transmission is encrypted with TLS, it still creates potential vulnerabilities from cyberattacks. If an attacker intercepts the credentials or accesses the server's database, they could reuse the client_secret indefinitely ^[4][9]. Because of this, symmetric authentication is only suitable for confidential clients that can securely store secrets but can't manage cryptographic keys. Importantly, SMART Backend Services do not support this method ^[9]. Asymmetric authentication offers a more secure alternative.

Asymmetric Authentication Using Public Keys

Asymmetric authentication uses public/private key pairs, also known as JSON Web Keys (JWK). Here’s how it works: the app generates a private key that stays securely stored and registers the corresponding public key with the EHR. Ideally, this is done by providing a URL to a JSON Web Key Set (JWKS), which allows for seamless key rotation without manual re-registration ^[8].

To request a token, the app creates a one-time signed JWT assertion to prove its identity. This assertion includes fields like:

The app signs this JWT with its private key and sends it to the authorization server. The server then validates the signature using the app’s registered public key. If everything checks out, the server issues an access token. Since the private key never leaves the app's secure environment, this method is much safer than symmetric authentication ^[8][4].

"Asymmetric ('private key JWT') authentication... is SMART's preferred authentication method because it avoids sending a shared secret over the wire." - HL7 International

The security benefits are clear. Even if someone intercepts the signed JWT, they can’t reuse it. The jti claim ensures each JWT is valid only once, and the short expiration window (often just five minutes) further limits any potential misuse ^[8][11]. Some systems, like Greenway Health's authorization server, allow JWT assertions to stay valid for up to 60 minutes, but this is the maximum ^[13].

Feature
Symmetric Authentication
Asymmetric Authentication






Shared

Public/Private Key Pair (JWK)





Secret sent in HTTP header

Private key never sent; signed JWT





Legacy/Alternative
Preferred Method





Not Supported

Required





Limited to TLS/Session
Built-in via

For healthcare organizations adopting SMART on FHIR, asymmetric authentication is the clear choice. It minimizes risks like credential leaks or reuse and includes built-in protections against replay attacks. While managing cryptographic keys adds complexity, the security benefits make it well worth the effort ^[4][8].

Token Exchange and Authorization Flows in SMART on FHIR

Token exchange processes are the backbone of secure data sharing in healthcare. They ensure that apps can access electronic health records (EHRs) safely and dynamically. After verifying its identity using asymmetric authentication, an app must gain permission to access EHR data through specific authorization flows.

Authorization Code Flow

The Authorization Code Flow is central to SMART on FHIR because it keeps user credentials separate from third-party apps. When a user launches an app, they are redirected to the EHR’s authorization server to authenticate.

Here’s how it works: Once the user logs in and approves the app's requested permissions, the authorization server sends a temporary authorization code back to the app. This code is short-lived, typically expiring in about one minute ^[6]. The app then exchanges this code for an access token by submitting it to the token endpoint along with a PKCE (Proof Key for Code Exchange) verifier. PKCE is mandatory for all SMART apps, as it prevents attackers from intercepting or tampering with authorization codes ^[6].

To enhance security, the app includes a state parameter with at least 122 bits of entropy (like a random UUID) in the authorization request. This defends against cross-site request forgery attacks ^[6]. Additionally, the aud (audience) parameter specifies the FHIR server’s URL, ensuring tokens aren’t mistakenly sent to malicious servers ^[6][7].

"The Authorization Code Grant... provides the distinct advantages of 1) enabling the end-user to authenticate directly to the authorization server, avoiding having to share credentials with the client; and 2) enabling the authorization server to transmit the access token directly to the client, rather than exposing it to the user-agent." - HL7 SMART on FHIR Best Practices

During token exchange, the server may also include launch context parameters, such as patient or encounter, to indicate which clinical record is active in the EHR ^[15]. This ensures the app opens directly to the appropriate patient chart without additional navigation.

Once the app secures the token, it can use refresh tokens to maintain access without repeatedly asking for authentication.

Refresh Tokens and User Identity Scopes

Access tokens are short-lived, typically expiring within one hour ^[6], to limit portfolio risk in case of theft. However, repeatedly asking users to log in would disrupt clinical workflows. This is where refresh tokens come into play.

Refresh tokens allow apps to request new access tokens without requiring the user to re-authenticate. This ensures uninterrupted access during tasks like long clinical sessions or background data syncing ^[6][16]. For public clients, such as mobile apps, authorization servers should issue a new refresh token with each refresh response. If an old refresh token is reused, it signals a potential security breach, prompting the server to invalidate the session ^[7][16].

SMART on FHIR uses refresh tokens to support both active user sessions and background processes. Two key scopes determine their behavior:

In addition to managing access, apps often need to identify the current user. The openid and fhirUser scopes enable this by initiating an OpenID Connect flow. When granted, the app receives an id_token with the user’s identity details, including a URL pointing to their FHIR resource (e.g., Practitioner/123 or Patient/456) ^[6][15]. This identity information helps apps personalize experiences and maintain accurate audit trails.

Feature
Access Token
Refresh Token






Authorizes requests to FHIR resources
Obtains new access tokens from auth server




Short-lived (typically < 1 hour)
Long-lived (days to months)




Resource Server (FHIR API)
Authorization Server (Token Endpoint)




Memory or short-term storage
Secure, persistent app-specific storage

Token Security and Clinical Interoperability

Token security is a cornerstone of ensuring secure clinical data exchanges and maintaining patient privacy in healthcare systems. With nearly 90% of non-federal acute care hospitals in the U.S. leveraging APIs for patient data access, and over half of health IT vendors integrating FHIR with OAuth 2.0, the importance of robust token security cannot be overstated ^[2].

At its core, token security relies on how tokens are created, validated, and used. Protocols like OAuth 2.0 and OpenID Connect establish a secure connection between apps and EHRs, while scope-based permissions enforce strict access control. For instance, an app with patient/Observation.read permission can only access observation data, limiting potential damage if the token is compromised ^[17][1].

Launch context simplifies workflows by automatically sending critical details - such as patient or encounter IDs - to the app, reducing manual errors and improving efficiency ^[18][2]. Furthermore, token introspection ensures real-time validation of access tokens, confirming their activity status and permissions ^[17]. Together, these measures enhance secure interoperability across various healthcare platforms.

Symmetric vs. Asymmetric Authentication

The choice of authentication method significantly impacts token security. The SMART on FHIR framework supports both symmetric and asymmetric authentication, but asymmetric methods are preferred. By keeping the private key secure within the client’s environment, asymmetric authentication eliminates the need to transmit shared secrets, reducing exposure risks ^[17]. Between 2021 and 2023-24, hospital adoption of FHIR-based API access surged from 56% to nearly 70%, with many organizations transitioning to asymmetric methods for enhanced security ^[2].

Reducing Token-Related Risks

Even with strong authentication protocols, tokens can be vulnerable to various threats:

To address these risks, healthcare organizations can implement several key strategies:

"If a refresh token is compromised and subsequently used by both the attacker and the legitimate client, one of them will present an invalidated refresh token, which will inform the authorization server of the breach." - SMART on FHIR Authorization Guide

Risk Management for Healthcare Organizations

As healthcare organizations increasingly integrate third-party applications, securing clinical systems that rely on token-based authentication becomes a top priority. To safeguard these systems, organizations must ensure that third-party apps meet core security standards. This includes using the Authorization Code Grant model to keep access tokens out of user-agents and enforcing mandatory TLS protocols for secure communication ^[7]. To address these challenges, many healthcare providers are turning to advanced risk management platforms.

Censinet RiskOps™ is one such platform designed to help healthcare organizations evaluate third-party integrations against critical security benchmarks. It allows teams to assess compliance with practices like refresh token rotation, audience parameter validation, and token introspection ^[7][10]. By centralizing these evaluations, organizations can proactively identify vulnerabilities, reducing the risk of patient data breaches or disruptions to clinical workflows.

However, risk management doesn’t stop at initial assessments. Continuous monitoring of token-related security measures is essential. For example, third-party apps should implement asymmetric authentication using JSON Web Key Sets (JWKS) and ensure refresh tokens are bound to specific clients ^[7][14]. For public apps that cannot securely store secrets, refresh token rotation - where a new token is issued with each use - is critical for quickly identifying breaches ^[7]. These practices align with established security standards and help maintain system integrity.

Sustaining strong token security also requires ongoing oversight. Censinet RiskOps™ facilitates this through automated workflows that monitor third-party risks across clinical apps, medical devices, and supply chains. The platform enables healthcare providers to share security evaluations and compare their token security practices with industry benchmarks. With Censinet AI™, risk teams can streamline vendor questionnaires and validate evidence more efficiently, scaling their efforts while maintaining the human judgment necessary for critical decisions.

To further strengthen defenses, organizations should establish protocols for high-risk scenarios. For instance, they should revoke refresh tokens if a device is lost or limit repeated invalid authorization attempts to prevent breaches ^[7]. Combining these operational controls with rigorous third-party assessments creates a layered defense strategy for managing token-based authentication risks, particularly in SMART on FHIR implementations. These practices are essential for ensuring secure and interoperable clinical systems under the SMART on FHIR framework.

Conclusion

Token-based authentication under SMART on FHIR plays a crucial role in achieving secure clinical interoperability. By tailoring OAuth 2.0 into a healthcare-specific protocol, SMART on FHIR establishes predictable and standardized connections between applications and Electronic Health Records (EHRs). As Raj Sankuratri explains:

"Plain OAuth 2.0 gives you a framework. SMART on FHIR gives you a protocol. That distinction matters when you are trying to connect healthcare systems at scale"
.

This system’s reliance on short-lived access tokens combined with long-term refresh tokens minimizes risks of unauthorized access. Additionally, granular scopes enforce the principle of least privilege, ensuring that applications only access the data they truly need. Real-world results reflect these benefits: organizations implementing SMART on FHIR patterns report a 30% to 50% drop in support effort post-launch, a 40% reduction in app onboarding time, and apps with embedded SMART flows see 2 to 3 times higher repeat usage compared to those requiring manual patient selection ^[20].

The move toward asymmetric authentication further bolsters security. By using public-private key cryptography, this approach eliminates shared secret vulnerabilities and strengthens the binding of tokens to specific devices. Combined with mandatory TLS 1.2 (or higher) and audience validation, these measures create multiple layers of protection against token-related threats.

Maintaining such security standards across third-party integrations requires consistent oversight. Tools like Censinet RiskOps™ enable healthcare teams to assess vendor compliance with token security protocols, monitor refresh token practices, and benchmark implementations against industry standards. This proactive approach not only prevents patient data breaches but also supports the seamless workflows critical to clinical interoperability.

As healthcare moves toward open ecosystems and greater patient control over data, token-based authentication under SMART on FHIR provides the scalable infrastructure needed to advance care delivery while safeguarding patient safety and data integrity.

FAQs

When should a SMART on FHIR app use asymmetric authentication instead of a client secret?

When a SMART on FHIR app requires stronger security measures, asymmetric authentication is the way to go. This method involves using asymmetric keys, such as RSA or EC private keys, to manage and sign assertions. It's particularly suited for situations where robust client authentication and secure key management are critical.

How do PKCE and the state parameter prevent authorization code attacks?

PKCE, or Proof Key for Code Exchange, adds an extra layer of security by preventing code interception during OAuth flows. It works by having the client generate a code verifier and a corresponding code challenge. The authorization server ties the authorization code to this challenge. When the client later exchanges the code for a token, it must provide the correct code verifier. This ensures that only the original client can successfully complete the exchange.

The state parameter is another critical security feature. It helps prevent Cross-Site Request Forgery (CSRF) attacks by maintaining a link between the client and server. Essentially, it verifies that the server's response corresponds to the client's original request, ensuring the integrity of the interaction.

What’s the safest way to store and rotate refresh tokens in SMART on FHIR apps?

To keep refresh tokens safe in SMART on FHIR apps, rely on encrypted storage or secure hardware modules to block unauthorized access. Always rotate tokens after each use, set them to expire after a specific period or number of uses, and keep an eye on token activity to spot anything unusual. Plus, make sure to use Transport Layer Security (TLS) for secure transmission, reducing the risk of token compromise.

Related Blog Posts

• IoT Device Authentication for Medical Devices: Guide
• Tokenization vs. Encryption: Which Is Better for PHI?
• FHIR and APIs: Building Secure Healthcare Systems
• How MFA Prevents Email Phishing in Healthcare

{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"When should a SMART on FHIR app use asymmetric authentication instead of a client secret?","acceptedAnswer":{"@type":"Answer","text":"<p>When a SMART on FHIR app requires stronger security measures, <strong>asymmetric authentication</strong> is the way to go. This method involves using asymmetric keys, such as RSA or EC private keys, to manage and sign assertions. It's particularly suited for situations where robust client authentication and secure key management are critical.</p>"}},{"@type":"Question","name":"How do PKCE and the state parameter prevent authorization code attacks?","acceptedAnswer":{"@type":"Answer","text":"<p>PKCE, or <strong>Proof Key for Code Exchange</strong>, adds an extra layer of security by preventing code interception during OAuth flows. It works by having the client generate a <strong>code verifier</strong> and a corresponding <strong>code challenge</strong>. The authorization server ties the authorization code to this challenge. When the client later exchanges the code for a token, it must provide the correct code verifier. This ensures that only the original client can successfully complete the exchange.</p> <p>The <strong>state parameter</strong> is another critical security feature. It helps prevent <strong>Cross-Site Request Forgery (CSRF)</strong> attacks by maintaining a link between the client and server. Essentially, it verifies that the server's response corresponds to the client's original request, ensuring the integrity of the interaction.</p>"}},{"@type":"Question","name":"What’s the safest way to store and rotate refresh tokens in SMART on FHIR apps?","acceptedAnswer":{"@type":"Answer","text":"<p>To keep refresh tokens safe in SMART on FHIR apps, rely on <strong>encrypted storage</strong> or secure hardware modules to block unauthorized access. Always rotate tokens after each use, set them to expire after a specific period or number of uses, and keep an eye on token activity to spot anything unusual. Plus, make sure to use <strong>Transport Layer Security (TLS)</strong> for secure transmission, reducing the risk of token compromise.</p>"}}]}