## The golden triangle: Kong, Okta, and FHIR

Together, these three technologies enable healthcare organizations to connect systems with confidence, manage identities responsibly, and share data securely.

• - **FHIR Server:** Your source of truth. It houses the health data (the patient, observation, and practitioner resources) and exposes it via the FHIR API.
• - **Okta: **Your identity and access management authority. It handles the complex work of authenticating users (patients, providers, etc.), managing their credentials, and issuing the access tokens that grant specific permissions according to the SMART on FHIR specification.
• - **Kong Gateway:** Your central control point. It sits in front of your FHIR server and inspects every single request. It intercepts calls, validates the tokens issued by Okta, and enforces security and traffic policies before a request is ever allowed to touch your backend FHIR service.

## Centralized security with Kong and Okta

Healthcare data is highly sensitive and strictly governed by regulations like HIPAA. The combination of Kong and Okta provides a robust, centralized security layer for your FHIR services. Here's how it works.

1. - **The SMART app launch:** A user in a third-party application (like a patient portal or a provider-facing app) clicks a button to access their health data. This kicks off the SMART on FHIR "launch sequence".
2. - **Redirect to Okta:** The application redirects the user to your Okta-powered login page. With Kong configured, you can seamlessly handle these redirects.
3. - **Authentication and consent:** The user authenticates with their credentials in Okta. Okta then displays a consent screen, where the user can approve the application's request for specific permissions (or scopes), such as patient/Patient.read or launch/patient.
4. - **Token issuance:** Once the user consents, Okta generates a secure access token (a JSON Web Token or JWT) that contains the approved scopes and information about the user and patient context. This token is sent back to the application.
5. - **API request via Kong:** The application now makes a request to the FHIR API, including the access token in the *Authorization* header. This request goes to Kong, not directly to the FHIR server.
6. - **Token validation at the edge:** This is where Kong plays a critical role. Using its OpenID Connect (OIDC) plugin, Kong intercepts the request, automatically communicates with Okta to validate the token's signature and claims, and ensures that the token is not expired.
7. - **Secure backend access:** Only if the token is valid, Kong allows the request to proceed to the backend FHIR server. This means your FHIR server is completely shielded from unauthenticated and unauthorized traffic.

This workflow offloads the entire authentication and authorization process to the specialists—Okta for identity management, and Kong for enforcement. This allows your FHIR service to focus solely on secure data delivery.

## Crafting compliant FHIR responses at the edge

A critical part of FHIR compliance is providing meaningful, standardized feedback, especially for errors. When something goes wrong, the FHIR standard specifies that the API should return an *OperationOutcome* resource. This provides far more detail than a generic *401 Unauthorized* or *429 Too Many Requests* message.

The problem is that many of these errors can originate from the gateway itself (e.g., rate limit exceeded, invalid API key). This is where Kong's ability to modify responses becomes essential.

You can configure Kong to intercept default gateway responses and transform them into fully compliant FHIR *OperationOutcome* resources.

• - **Using the *****response-transformer***** plugin:** For common errors, this plugin is perfect. You can configure it to catch specific status codes (like a *401* from the OIDC plugin or a *429 *from the rate-limiting plugin) and replace the generic response body with a pre-defined, FHIR-compliant JSON object.
• - **Using serverless functions for dynamic responses:** For more complex scenarios, you can use Kong's serverless functions capabilities (e.g., the *pre-function* and *post-function* plugins). This lets you write custom code (in Lua) that runs directly on the gateway to dynamically construct an *OperationOutcome*. You could inspect headers, check parts of the request, and build a detailed, context-specific error message on the fly.

Here’s an example of what a gateway-generated *OperationOutcome* for a failed authentication attempt might look like.

{
  "resourceType": "OperationOutcome",
  "issue": [
    {
      "severity": "error",
      "code": "security",
      "diagnostics": "Authentication failed: The provided access token is invalid or has expired. Please re-authenticate and try again.",
      "details": {
        "text": "Error handled by API Gateway."
      }
    }
  ]
}

By handling this at the edge, you ensure that every single response from your API endpoint, whether from your backend FHIR server or the gateway itself, is perfectly compliant. This dramatically improves interoperability and the overall developer experience for teams building applications on your platform.

## Beyond authentication: The power of Kong plugins

In addition to authentication and response transformation capabilities, Kong provides a rich ecosystem of plugins to further enhance your FHIR services. These plugins help you with the following.

• - **Rate limiting**: Protect your FHIR server from being overwhelmed by setting limits on how many requests a user or application can make in a given time. This is critical for ensuring fair usage and high availability.
• - **Caching**: Some FHIR data, like practitioner details or clinic locations, doesn't change very often. Kong can cache these responses to deliver them instantly to users while reducing the load on your backend.
• - **Full observability and auditing**: When dealing with protected health information (PHI) and/or personally identifiable information (PII), a detailed audit trail is legally mandatory. Kong can log every single API request and response to give you complete visibility into who accessed which data and when. You can feed this data into monitoring tools like Prometheus and Grafana for real-time insights into the health and usage of your FHIR APIs.

By combining the SMART on FHIR standard with the identity management power of Okta and the robust security and management capabilities of Kong Gateway, healthcare organizations can build a truly secure, scalable, and resilient platform for the future of interoperable health data.

### Conclusion

Bringing together SMART on FHIR, Kong Gateway, and Okta isn’t just another tech stack — it’s the backbone of the next wave of healthcare innovation. As providers rush to improve healthcare outcomes while keeping patient data under lock and key, this trio of technologies gives them a clear path forward.

Kong Gateway — trusted by enterprises worldwide and built to handle billions of API calls — offers scalability, security, and flexibility. Whether you’re running on-prem, in the cloud, or somewhere in between, Kong fits right in and grows as you scale. And with an extensive plugin ecosystem, you won’t have to rip and replace when standards or regulations shift — you can keep pace without missing a beat.

Ready to put it to work? Sign up for [Kong Konnect](https://konghq.com/products/kong-konnect/register)Kong Konnect for free, or book a personalized demo to see how this architecture can take your platform to the next level.