Running your own open source OpenID Connect server gives you full control over authentication and identity management, no vendor lock-in, no per-user fees, and no black-box token handling. For teams building healthcare applications, where OAuth 2.0 and OIDC underpin protocols like SMART on FHIR, that control can be especially valuable.

But not every open source OIDC implementation is built the same. Some are lightweight and developer-friendly. Others are enterprise-grade platforms with built-in multi-tenancy, consent management, and compliance features. Picking the wrong one means wasted engineering time and potential security gaps, picking the right one means you get a rock-solid identity layer that grows with your product. The trick is knowing which server fits your use case before you commit.

At SoFaaS™, we handle OAuth and authorization management as part of our managed SMART on FHIR platform, so healthcare teams don't have to build token flows and consent handling from scratch. But we know that many organizations still need or prefer to run their own OIDC infrastructure, and we respect that. This guide breaks down 12 of the best open source OpenID Connect servers you can self-host, covering their strengths, trade-offs, and ideal use cases so you can make an informed decision.

1. Keycloak

Keycloak, backed by Red Hat, is the most widely deployed open source OpenID Connect server in the enterprise world. It covers everything from basic token issuance to complex multi-realm identity federation, making it the default choice teams reach for when they need proven, battle-tested IAM infrastructure without paying per-user licensing fees.

What it is

Keycloak is a full-featured identity and access management platform that supports OpenID Connect, OAuth 2.0, and SAML 2.0 natively. It ships with a browser-based admin console, user federation, social login, admin REST APIs, and client adapters for a wide range of languages and frameworks. Red Hat maintains the project, and the open source community around it is one of the most active in the IAM space, which means bugs get fixed quickly and documentation stays reasonably current.

Best for

Keycloak fits teams that need a comprehensive, enterprise-grade identity platform and have the infrastructure resources to run it responsibly. It works especially well for organizations managing multiple applications or services that require centralized authentication, role-based access control, and support for both legacy SAML and modern OIDC flows from a single deployment.

Standout features

Keycloak packs a feature set that most other self-hosted OIDC servers don't match out of the box:

• Multi-realm and multi-tenant support: Isolate authentication for different applications or business units within one deployment.
• User federation: Connect directly to LDAP or Active Directory without writing custom connectors.
• Fine-grained authorization: Move beyond basic role checks with policy-based access control built into the platform.
• Identity brokering: Delegate authentication to external providers like Google with minimal configuration.

Tradeoffs to know

Keycloak's depth of features comes with real operational complexity. The admin console is powerful but has a noticeable learning curve, and the default out-of-the-box configuration is not production-ready without deliberate tuning. You will spend time on clustering, caching configuration, and database setup before it runs reliably under load.

If your only requirement is a lightweight OIDC token endpoint, Keycloak will feel like significantly more than you need.

Self-hosting notes

Keycloak runs on the Quarkus runtime (since version 17) and supports containerized deployment via Docker and Kubernetes. For production, you should configure an external relational database (PostgreSQL is the most common choice), set up a reverse proxy for TLS termination, and plan your high-availability clustering strategy before you go live rather than retrofitting it later. The official documentation covers HA setups in detail, but expect meaningful DevOps effort to reach a stable, scalable configuration.

Licensing and pricing

Keycloak is free and open source under the Apache 2.0 license, meaning you can use it commercially without paying licensing fees. Red Hat offers a supported enterprise version called Red Hat Build of Keycloak, which comes with paid support contracts and guaranteed SLAs. For most teams, the community version is sufficient unless you require vendor-backed support for production incidents.

2. Ory Hydra

Ory Hydra takes a fundamentally different approach from Keycloak. Rather than bundling identity management, user storage, and authentication flows into one monolithic platform, it focuses exclusively on being an OAuth 2.0 and OpenID Connect authorization server, leaving user management entirely to your existing systems.

What it is

Ory Hydra is a certified open source OpenID Connect server built in Go, designed to handle OAuth 2.0 authorization and OIDC token management without acting as a user store or login UI. It delegates authentication and consent decisions to your own application through a redirect-based flow, which keeps the core server lean and highly adaptable to your existing stack.

Best for

Hydra works best for development teams that already have identity and user management infrastructure in place and only need a standards-compliant token layer on top of it. If you run an existing user database with its own login flow and want to layer OIDC on top without rebuilding that flow, Hydra fills that gap without forcing a migration.

Standout features

• Headless architecture: No built-in login UI means you fully control the user-facing experience.
• High throughput: Written in Go, Hydra handles high request volumes with a minimal resource footprint.
• OpenID certified: Ory Hydra holds official OpenID Connect certification, so you know it handles spec compliance correctly.

Tradeoffs to know

The headless model that makes Hydra so flexible also means significantly more custom development work upfront. You need to build and host your own login and consent application that Hydra redirects to during authorization flows, which adds real engineering effort before you can issue your first token.

If your team lacks dedicated backend engineering capacity, Hydra's architecture will slow your deployment more than it helps.

Self-hosting notes

Hydra runs as a single stateless binary and persists data in PostgreSQL, MySQL, or CockroachDB. Docker and Kubernetes deployments are well documented in the official Ory documentation, and the stateless design makes horizontal scaling straightforward once your database layer is stable.

Licensing and pricing

Ory Hydra is free under the Apache 2.0 license. Ory also offers a managed cloud product with paid tiers if you want to offload infrastructure operations entirely.

3. ZITADEL

ZITADEL is a newer entrant in the open source OpenID Connect server space that has gained traction quickly by combining modern developer tooling with a production-ready feature set. Where Keycloak leans on years of enterprise adoption and Hydra stays intentionally minimal, ZITADEL sits in the middle, offering built-in user management and an OIDC-compliant authorization layer in a single, modern platform.

What it is

ZITADEL is an open source identity platform built in Go, designed for cloud-native environments from the start. It handles OpenID Connect, OAuth 2.0, and SAML, and ships with a built-in login UI, user registration, and multi-factor authentication without extra plugins. Event sourcing powers the underlying data model, which gives ZITADEL a complete, queryable audit trail without any additional configuration work on your end.

Best for

ZITADEL fits teams that want the convenience of a bundled login UI and user management without the operational complexity of running Keycloak. It works particularly well for SaaS products that serve multiple organizations and need solid multi-tenancy isolation from day one rather than bolting it on later.

Standout features

ZITADEL packs several capabilities that stand out relative to other self-hosted identity platforms at a similar maturity level. Native multi-tenancy and built-in passwordless authentication give you a meaningful head start on features that other servers require plugins or custom development to deliver.

• Native multi-tenancy: Organizations are isolated cleanly at the platform level without complex realm configuration.
• Event-sourced data model: Every state change is stored as an event, giving you a full auditable history.
• Built-in MFA and passkeys: TOTP, WebAuthn, and passwordless flows ship out of the box.

ZITADEL's event-sourced architecture makes compliance auditing considerably easier, which is a real advantage for teams operating in regulated industries.

Tradeoffs to know

ZITADEL is younger than Keycloak or Hydra, so the community is smaller and some documentation gaps appear in edge-case scenarios. The event sourcing model also generates higher database write volumes over time, meaning you need to plan your storage and database maintenance strategy carefully before you scale.

Self-hosting notes

ZITADEL deploys as a single binary and uses PostgreSQL as its primary database. Docker and Helm chart deployments are well documented, and horizontal scaling is supported once your database layer is stable and properly tuned.

Licensing and pricing

ZITADEL's core platform is free under the Apache 2.0 license. A managed cloud offering with paid tiers is available if you want to skip infrastructure management without forking the project or building custom automation.

4. authentik

authentik (stylized in lowercase) is a newer identity platform that has built a strong following among self-hosted infrastructure enthusiasts and developer-focused teams. It brings together an OIDC authorization server, a full login UI, and an extensible policy engine in a single deployment that stays approachable even if your team doesn't have dedicated IAM expertise.

What it is

authentik is an open source OpenID Connect server built in Python and TypeScript, designed to cover authentication, authorization, and user management in one platform. It supports OAuth 2.0, OIDC, SAML, LDAP, and SCIM, and ships with a polished admin interface that makes configuration significantly more accessible than Keycloak's console for newcomers.

Best for

authentik works best for teams running self-hosted infrastructure stacks who want a capable identity provider without investing weeks in operational setup. It fits internal tooling environments and small-to-mid-size SaaS products that need solid OIDC support alongside proxy-based authentication for applications that don't speak OIDC natively.

Standout features

• Flow-based authentication engine: Build custom login, enrollment, and recovery flows using a visual editor rather than writing custom code.
• Outpost architecture: Deploy lightweight proxies that enforce authentication in front of applications that don't support OIDC directly.
• Built-in SCIM support: Sync users and groups to connected applications automatically without manual provisioning scripts.

The flow-based engine lets you model complex authentication logic without touching a line of code, which meaningfully reduces implementation time for non-trivial login requirements.

Tradeoffs to know

authentik's Python-based backend introduces higher memory usage compared to Go-based alternatives like Hydra or ZITADEL, which matters when you run it on resource-constrained hardware. The active community is smaller than Keycloak's, so niche configuration questions can take longer to get answered through community forums.

Self-hosting notes

authentik deploys via Docker Compose or Helm on Kubernetes, with PostgreSQL and Redis as required dependencies. Both deployment paths are well documented in the official project documentation, and updates ship frequently enough that you should plan a regular patch cadence.

Licensing and pricing

authentik is free under the MIT license. An Enterprise tier is available with paid support and additional features like fine-grained RBAC and audit log exports for teams that need them.

5. Dex

Dex, originally built by CoreOS and now maintained under the CNCF ecosystem, is a federated identity provider written in Go. Rather than managing users directly, it lets you delegate authentication to existing upstream identity sources like LDAP, GitHub, or other OIDC providers, then issues standard OIDC tokens to your applications.

What it is

As a focused open source OpenID Connect server, Dex acts as an identity middleware layer. It accepts authentication from an external provider and translates those identities into standard OIDC tokens that any compliant application can consume, without requiring changes to your existing user directory.

Best for

Teams that need to federate authentication across multiple identity backends without rebuilding their directory infrastructure will find Dex a strong fit. It works especially well in Kubernetes environments, where it ships as the default OIDC provider in several cluster management tools.

Standout features

Dex's connector model is its defining strength, giving you pre-built bridges to a wide range of upstream systems without custom integration code.

• Connector model: Supports LDAP, Active Directory, GitHub, GitLab, Google, SAML, and other OIDC providers out of the box.
• Kubernetes-native design: Built with cluster-level SSO in mind from the start.
• Minimal footprint: Low memory and CPU overhead thanks to the Go runtime.

Tradeoffs to know

Dex is narrow in scope by design, which means it handles federated token issuance well but lacks the built-in user management, admin console, and fine-grained authorization policies that platforms like Keycloak or ZITADEL offer. If your requirements grow beyond federation, you will likely outgrow it faster than you expect.

Dex works best as a bridge between your existing identity systems and OIDC-dependent applications, not as a standalone identity platform.

Self-hosting notes

Running Dex means deploying a single Go binary backed by a supported storage layer: SQLite for development, or PostgreSQL, MySQL, or etcd for production. Kubernetes deployment via Helm is the most common path, and the official documentation covers connector configuration for each upstream provider in detail.

Licensing and pricing

Dex is free under the Apache 2.0 license. No commercial tiers or paid support contracts exist from the core project maintainers, so you rely entirely on community support for production issues.

6. OpenIddict

OpenIddict is a flexible OAuth 2.0 and OpenID Connect framework for .NET developers who want to embed authorization server capabilities directly into their existing application rather than running a separate identity service.

What it is

OpenIddict functions as an open source OpenID Connect server built entirely on ASP.NET Core, which means the authorization server lives inside your application process rather than as a standalone deployment. It handles token issuance, validation, and revocation natively and integrates tightly with Entity Framework Core for persistence, giving .NET teams a familiar development experience from day one.

Best for

OpenIddict suits .NET development teams who already own an ASP.NET Core application and want to add standards-compliant OAuth 2.0 and OIDC flows without introducing a separate server that requires its own infrastructure and operational overhead.

If your team lives in the .NET ecosystem and wants to avoid the operational burden of running a separate identity service, OpenIddict is the most direct path.

Standout features

• Deep ASP.NET Core integration: Uses native dependency injection, middleware, and EF Core rather than imposing its own patterns.
• Token flexibility: Supports both opaque tokens and JSON Web Tokens depending on your validation requirements.
• Device code flow: Ships with full RFC 8628 support for IoT and CLI authentication scenarios out of the box.

Tradeoffs to know

OpenIddict lacks the built-in admin console and user management UI that platforms like Keycloak or authentik provide. You build those interfaces yourself, which adds meaningful development time if you need a self-service user portal or administrative dashboard beyond what your application already exposes.

Self-hosting notes

Because OpenIddict runs inside your ASP.NET Core application, your existing hosting infrastructure handles deployment automatically. You configure it through standard .NET dependency injection and point it at your existing database managed by Entity Framework Core, which removes most of the infrastructure setup work.

Licensing and pricing

OpenIddict is free under the Apache 2.0 license. No paid tiers exist, and the project relies entirely on community contributions and sponsorships for ongoing maintenance.

7. WSO2 Identity Server

WSO2 Identity Server is a mature, enterprise-grade open source OpenID Connect server maintained by WSO2, a company with deep roots in API management and integration middleware. It delivers a comprehensive identity platform that covers authentication, authorization, identity federation, and user management under a single deployment.

What it is

WSO2 Identity Server is a Java-based identity and access management platform that supports OpenID Connect, OAuth 2.0, SAML 2.0, and WS-Federation natively. Built on the OSGi component framework, it ships with a centralized management console, user store connectors, and a broad set of authentication protocols, making it one of the more feature-complete self-hosted identity platforms available without a licensing fee.

Best for

WSO2 Identity Server fits large enterprises that already run WSO2 middleware products like the API Manager or Enterprise Integrator, where tight integration between identity and API gateway layers adds real operational value. It also suits organizations that need broad protocol support across OIDC, SAML, and WS-Federation from a single platform rather than running multiple specialized services.

Standout features

• Adaptive authentication: Build step-up authentication flows using a JavaScript-based policy engine without writing complex backend logic.
• Identity federation: Connect to external identity providers including social logins and enterprise directories through a unified interface.
• Fine-grained authorization: Includes XACML-based access control policies for teams that need more than basic role-based rules.

If your organization already runs WSO2 API Manager, pairing it with WSO2 Identity Server saves meaningful integration work compared to deploying a separate identity platform.

Tradeoffs to know

WSO2 Identity Server runs on the JVM with a relatively high memory baseline, which means you need to plan your infrastructure sizing carefully before going to production. The configuration depth that makes it powerful also introduces a steep learning curve for teams without prior WSO2 experience, and the management console feels less modern than newer platforms like authentik or ZITADEL.

Self-hosting notes

You deploy WSO2 Identity Server as a Java application on Linux, containerized via Docker, or orchestrated on Kubernetes using official Helm charts. PostgreSQL, MySQL, and Oracle are supported as external databases for production use, and the documentation covers clustered high-availability configurations thoroughly.

Licensing and pricing

WSO2 Identity Server is free under the Apache 2.0 license. WSO2 offers paid enterprise support subscriptions that include SLA-backed incident response and access to professional services for teams that need vendor-backed production coverage.

8. Janssen

Janssen is a Linux Foundation project that provides an enterprise-grade open source OpenID Connect server built for high-scale deployments in regulated industries. It traces its lineage to the Gluu Server codebase, which Gluu donated to the Linux Foundation to give the project neutral governance and long-term sustainability.

What it is

This platform delivers a modular identity and access management system that supports OpenID Connect, OAuth 2.0, FIDO2, UMA (User-Managed Access), and SCIM. Each capability ships as a separate microservice, so you can deploy only the components your stack actually needs rather than running the full platform from day one.

Best for

Janssen suits large organizations and government agencies that need a highly scalable, standards-compliant identity layer with strong support for FIDO2 passwordless authentication. It fits healthcare teams particularly well when regulatory compliance and high-volume token issuance are both non-negotiable requirements.

Janssen's Linux Foundation governance means the project won't disappear if a single vendor changes direction, which matters when you're making long-term infrastructure commitments.

Standout features

Few self-hosted platforms match Janssen's standards breadth and modular flexibility at this scale. The architecture lets you add or remove components without touching the rest of your deployment.

• FIDO2 and passkey support: Native passwordless authentication without third-party plugins.
• Dynamic client registration: Applications register themselves programmatically using the OIDC spec.
• Modular architecture: Deploy and scale individual services independently based on actual load.

Tradeoffs to know

The modular microservices architecture is powerful but adds significant operational complexity compared to single-binary alternatives. You need solid Kubernetes expertise to manage the service mesh effectively, and documentation is still catching up with the platform's full capabilities following the transition from Gluu.

Self-hosting notes

Janssen runs on Kubernetes using official Helm charts and requires a supported LDAP or relational database backend. The project recommends production deployments on at least a three-node cluster to satisfy the high-availability expectations of its enterprise audience.

Licensing and pricing

Janssen is free and open source under the Apache 2.0 license. No paid tiers exist from the project itself, though commercial support is available through third-party vendors with deep experience in the Gluu/Janssen codebase.

9. Authelia

Authelia is a lightweight authentication and authorization server built in Go, designed to act as a single sign-on (SSO) gateway for self-hosted infrastructure. It protects applications sitting behind a reverse proxy rather than functioning as a traditional identity provider that applications connect to directly.

What it is

Authelia handles multi-factor authentication, SSO, and access control for applications that run behind reverse proxies like Nginx, Traefik, or Caddy. It supports OpenID Connect as an authorization server, which means it can act as an open source openid connect server for connected applications that speak the standard. The project is written in Go and is actively maintained with a stable release cadence.

Best for

Authelia works best for homelab operators and small self-hosted infrastructure stacks where the primary goal is protecting a collection of internal services with a single login point and MFA enforcement. If your team needs to secure internal dashboards, private applications, or developer tooling behind a consistent authentication layer without running a heavyweight IAM platform, Authelia delivers that with considerably less infrastructure overhead.

Standout features

• Reverse proxy integration: Works natively with Nginx, Traefik, HAProxy, and Caddy using forward authentication headers.
• TOTP and WebAuthn: Ships with both time-based one-time passwords and hardware key support out of the box.
• Per-domain access rules: Define fine-grained access policies per subdomain or URL path without custom middleware.

Authelia's reverse proxy model means you protect applications without modifying them at all, which saves significant integration time for teams running large numbers of internal services.

Tradeoffs to know

Authelia is not a full identity management platform, so it lacks the user federation, enterprise directory connectors, and delegated administration features that platforms like Keycloak or WSO2 provide. For production environments requiring deep IAM capabilities, you will likely outgrow it.

Self-hosting notes

Authelia runs as a single Docker container and uses Redis for session storage and either YAML files or a small database for configuration. The official documentation covers Traefik and Nginx integration in detail.

Licensing and pricing

Authelia is free under the Apache 2.0 license with no paid tiers.

10. node-oidc-provider

node-oidc-provider is a certified open source OpenID Connect server written in Node.js, built for developers who want a standards-compliant authorization server they can embed directly into an existing JavaScript or TypeScript application. It handles the full OIDC spec without imposing UI or business logic, leaving those concerns entirely to you.

What it is

node-oidc-provider is a low-level OpenID Connect and OAuth 2.0 library maintained by Panva, designed to run inside a Node.js application rather than as a standalone deployment. It implements the core OIDC specification plus a wide range of extensions, including PKCE, Pushed Authorization Requests (PAR), JWT Secured Authorization Response Mode (JARM), and Device Authorization Grant. The library holds official OpenID certification, so spec compliance is not something you need to verify yourself.

Best for

This library fits Node.js backend teams that want precise control over every aspect of their authorization server behavior without inheriting someone else's architectural opinions. If your team already runs a Node.js API or service and wants to add OIDC token issuance without deploying and operating a separate server, node-oidc-provider gives you that path with minimal infrastructure overhead.

Standout features

• OpenID certified: Passes the official conformance test suite across multiple profiles.
• Highly configurable: Almost every behavior is overridable through adapter interfaces and interaction handlers.
• Broad grant type support: Covers authorization code, device flow, client credentials, and refresh token flows out of the box.

Tradeoffs to know

node-oidc-provider ships with no built-in UI, no user store, and no admin console. You build every user-facing piece yourself, which means a significant amount of custom code before your first working login screen appears.

If your team underestimates the custom development involved, the timeline will slip considerably before you reach production.

Self-hosting notes

You embed node-oidc-provider directly into your Node.js application and connect it to your existing database through a custom adapter. No separate binary or container is required.

Licensing and pricing

node-oidc-provider is free under the MIT license with no paid tiers or commercial support contracts from the maintainer.

11. MITREid Connect

MITREid Connect is one of the original Java-based OpenID Connect reference implementations, developed by MITRE Corporation and MIT. It served as an early proof-of-concept for the OIDC specification itself, making it historically significant even if the project's active development has largely stalled in recent years.

What it is

MITREid Connect is a Spring-based open source OpenID Connect server built in Java, implementing the core OIDC and OAuth 2.0 specifications along with several related extensions. It was designed to demonstrate the full OpenID Connect specification in a working codebase, and it served as a reference implementation that other teams studied when the standard was still gaining adoption. The project lives on GitHub under the OpenID Foundation's organization.

Best for

MITREid Connect fits teams operating in Java Spring environments that need a reference point for how OIDC flows should work under the spec. It also suits research and academic contexts where studying a canonical implementation of the specification matters more than long-term production support.

If you are building a production system that requires active patches and community support, MITREid Connect is not the right starting point given its maintenance status.

Standout features

• Full OIDC compliance: Implements the core specification with extensions including discovery, dynamic registration, and session management.
• Spring Security integration: Fits naturally into existing Java Spring application stacks without requiring a separate runtime or framework.
• UMA support: Includes basic User-Managed Access flow support alongside the standard OIDC feature set.

Tradeoffs to know

The most significant issue with MITREid Connect is that active development has effectively stopped, leaving known issues unresolved and dependency versions outdated. Running it in a production environment today means accepting meaningful security and maintenance risk that other options on this list do not carry.

Self-hosting notes

You deploy MITREid Connect as a standard Java web application on a servlet container like Tomcat, backed by a relational database through Spring Data JPA. Setup follows familiar Spring application patterns, but you should expect to handle dependency upgrades manually given the lack of active maintainers.

Licensing and pricing

MITREid Connect is free under the Apache 2.0 license with no paid tiers or commercial support available.

12. Shibboleth OIDC OP plugin

The Shibboleth OIDC OP plugin extends the Shibboleth Identity Provider with OpenID Connect authorization server capabilities, giving institutions that already run Shibboleth IdP a path to supporting modern OIDC clients without replacing their existing infrastructure.

What it is

This plugin turns a standard Shibboleth IdP deployment into a functioning open source openid connect server by adding OIDC endpoints alongside the existing SAML flows. It is maintained by the Shibboleth Consortium and integrates directly into the Shibboleth IdP's attribute release and consent framework, so your existing policy configurations carry over without requiring a parallel setup.

Best for

The plugin fits universities, research institutions, and government agencies that already run Shibboleth IdP at the core of their identity federation and need to extend support to newer applications that speak OIDC rather than SAML. If your organization has years of Shibboleth configuration invested, adding this plugin is far more practical than migrating to a different platform.

Adding OIDC support through the plugin means you avoid a full IdP migration while still serving modern applications that don't speak SAML.

Standout features

• SAML and OIDC from one IdP: Serve both protocol families from a single deployment without running parallel identity infrastructure.
• Attribute release compatibility: Your existing Shibboleth attribute filters and consent policies apply to OIDC token issuance without separate configuration.
• Federation-aware design: Works naturally within InCommon and eduGAIN federated identity ecosystems.

Tradeoffs to know

The plugin is tightly coupled to Shibboleth IdP, so if you don't already run Shibboleth, there is no practical reason to adopt it. Feature development moves slowly relative to standalone platforms, and documentation assumes deep familiarity with the Shibboleth configuration model, which creates a steep on-ramp for anyone outside the academic IT community.

Self-hosting notes

You install the plugin into an existing Shibboleth IdP installation running on a Java servlet container like Jetty or Tomcat. No separate binary or additional database is required beyond what your current Shibboleth deployment already uses.

Licensing and pricing

The plugin is free under the Apache 2.0 license, maintained by the Shibboleth Consortium with no paid tiers or commercial support contracts available directly from the project.

Final thoughts

Choosing the right open source OpenID Connect server comes down to your team's stack, your infrastructure capacity, and how much custom development you can realistically absorb. If you need a full enterprise IAM platform, Keycloak or ZITADEL are the strongest starting points. If you want something narrow and composable, Ory Hydra or Dex will serve you better. And if you live in .NET, OpenIddict removes most of the overhead entirely.

For healthcare teams building SMART on FHIR applications, running your own OIDC infrastructure is only part of the picture. OAuth flows, patient consent management, and token handling all need to work correctly against real EHR systems before you ship anything to users. If you want to skip the integration complexity and connect to Epic, Cerner, and Allscripts in days rather than months, see how SoFaaS handles SMART on FHIR authorization for you.