When a health system launches a SMART on FHIR app inside EPIC, authentication has to work seamlessly, and that usually means the app needs to play nicely with the identity provider the health system already trusts. More often than not, that provider is Microsoft Entra ID (formerly Azure AD). Understanding Azure AD identity federation is essential for any healthcare vendor building integrations that touch clinical workflows, because federation is the mechanism that lets users authenticate once and access resources across organizational boundaries without juggling separate credentials.

At its core, identity federation establishes trust between two or more domains so that a user authenticated in one system can be recognized in another. For healthcare vendors, this matters directly: health systems expect your application to honor their existing identity infrastructure, not force clinicians into yet another login screen. Getting this wrong means friction in procurement conversations, failed security reviews, and lost contracts. Getting it right means your product slots into the clinical environment like it belongs there, which is exactly the kind of seamless EPIC integration VectorCare's no-code platform is built to deliver, handling the FHIR, OAuth, and compliance layers so you can focus on your product.

This article breaks down what Azure AD identity federation actually is, how it differs from single sign-on, the architectural patterns behind it, and how federated authentication works in hybrid and cloud environments. Whether you're evaluating your integration architecture or preparing for a health system's security review, this guide gives you the technical foundation to make informed decisions.

Why Azure AD identity federation matters

Healthcare IT departments don't treat authentication as a nice-to-have feature. When a clinical application touches patient data or prescription workflows, the security review that precedes any contract is thorough and often unforgiving. For vendors selling into health systems, your application's authentication model gets scrutinized long before anyone discusses pricing or deployment timelines. Azure AD identity federation is not just a technical detail; it's a procurement checkpoint that health systems use to determine whether your product fits into their existing security posture without introducing new risk.

The cost of getting identity wrong in healthcare

Health systems have invested heavily in their Microsoft Entra ID infrastructure, and they expect clinical tools to integrate with it rather than around it. When a vendor's application requires clinicians to maintain a separate username and password, two things happen immediately: user adoption drops, and the security team raises a flag about credential sprawl. Credential sprawl is exactly what enterprise IT teams work to eliminate, because each additional set of credentials represents another attack surface that needs monitoring, management, and eventual deprovisioning when staff members leave.

A failed authentication integration is often the reason a technically sound product loses a health system contract before it ever reaches a clinical pilot.

The financial stakes compound the security concern. If your product requires months of custom identity work before it can pass a health system's security review, you're absorbing engineering costs that your competitors may not be carrying. Vendors who arrive at a procurement conversation with federated authentication already implemented shorten the security review cycle significantly. That speed advantage translates directly into faster contract execution, which matters when health systems are evaluating multiple vendors for the same clinical use case.

How federation changes the procurement dynamic

When your application supports federation with a health system's identity provider, clinicians authenticate using their existing Active Directory or Entra ID credentials without any additional provisioning on your end. The health system's IT team retains full control over who can access the application, which satisfies their governance requirements directly. Governance and access control are primary concerns in HIPAA audits, and demonstrating that your application respects the health system's identity perimeter removes a significant objection from the security review process before the conversation even starts.

Federation also signals organizational maturity to procurement teams. A vendor that has already solved federated authentication demonstrates that it understands the operational reality of clinical environments, where IT teams manage hundreds of applications across dozens of vendors simultaneously. When your product arrives already configured for standards-based federation, you move from the "needs integration work" category to the "ready to deploy" category. That distinction shortens sales cycles and increases your win rate for contracts where multiple vendors are competing on similar clinical capabilities, giving you an advantage that has nothing to do with your core product's features.

Key terms and components you must know

Before you configure azure ad identity federation or walk into a security review conversation with a health system, you need a clear vocabulary. These terms appear constantly in federation documentation, procurement questionnaires, and architecture diagrams, and misunderstanding even one of them can send a technical discussion sideways fast.

Identity providers and relying parties

An identity provider (IdP) is the system that authenticates users and asserts their identity to other applications. In most health system environments, Microsoft Entra ID acts as the IdP, meaning it holds the user directory, enforces MFA policies, and issues proof of authentication. A relying party (RP) is any application or service that trusts the IdP's assertions and grants access based on them. Your application is the relying party. The health system's Entra ID tenant tells your app who the user is, and your app decides what that user can do based on that information.

The distinction between IdP and relying party is the foundational mental model for every federation conversation you will have with a health system's security team.

Federated trust flows only when both sides agree on a trust anchor, which is typically a metadata document or certificate that each party exchanges during setup. Without that anchor, neither side can verify that tokens it receives are legitimate.

Protocols, tokens, and claims

Federation relies on standardized protocols to pass authentication data between systems. SAML 2.0 and OpenID Connect (OIDC) are the two protocols you encounter most often in healthcare integrations. SAML passes authentication assertions as signed XML documents, while OIDC passes them as JSON Web Tokens (JWTs), which are compact and easier to parse in modern web applications. Microsoft Entra ID supports both, so your integration choice usually depends on what the target application framework handles best.

Inside every token are claims, which are key-value pairs that describe the authenticated user. Common claims include the user's unique identifier, email address, group memberships, and roles. Your application reads these claims to make authorization decisions without maintaining its own user directory. Understanding which claims a health system's Entra ID tenant will include in the token it issues to your app is a practical detail that determines how much user-mapping work you need to do on your end.

How Azure AD federation works step by step

Azure AD identity federation follows a predictable sequence every time a user tries to access a federated resource. Understanding that sequence helps you configure your application correctly and diagnose problems when authentication fails in a health system environment. Each step in the flow has a corresponding component that can be tuned, monitored, or misconfigured, so knowing the order matters as much as knowing the individual parts.

The initial authentication request

When a user navigates to your application, your app checks whether the user already holds a valid session. If no session exists, your application redirects the user's browser to Microsoft Entra ID with an authentication request that includes your application's client ID and the requested scopes. The user never enters credentials directly into your app. Instead, the browser travels to the Entra ID login endpoint, where the health system's conditional access policies and MFA requirements are enforced before any credential is verified.

This redirect model is the foundation of federated security: your application never sees the user's password, which removes an entire class of credential-handling risk from your attack surface.

Token issuance and validation

After the user authenticates successfully, Entra ID signs a token (either a SAML assertion or a JWT, depending on your protocol) and sends it back to your application's registered redirect URI. Your application then validates that token by checking the signature against the public keys Microsoft publishes in its OpenID Connect discovery document, available at your tenant's well-known endpoint. Skipping signature validation is a critical mistake. Without it, your application cannot distinguish a legitimate token from a forged one, which nullifies the security model entirely.

Access grant and session management

Once your application confirms the token's validity, it reads the claims inside the token to identify the user and determine their permissions. Common claims include the user's object ID, email address, and group memberships. Your application maps these claims to internal roles, creates a local session, and grants access accordingly. The token's expiration time controls how long that session remains valid before your application requires re-authentication. Configuring appropriate token lifetimes matters in clinical settings where long-running shifts are common but security policies still require periodic re-validation. Microsoft's documentation on configurable token lifetimes covers the specific parameters you can adjust inside Entra ID.

Federation vs SSO vs sync and pass-through auth

These four terms appear in the same conversation constantly, and health system security teams sometimes use them as though they mean the same thing. Knowing the exact distinction between each approach keeps you from specifying the wrong architecture in a procurement questionnaire or selecting the wrong authentication method during a health system integration review. Each option solves a different problem and carries different tradeoffs around security, infrastructure requirements, and operational overhead.

What single sign-on actually means

Single sign-on (SSO) describes the experience of authenticating once and then accessing multiple applications without re-entering credentials. Federation is one mechanism that delivers SSO, but SSO itself is a user experience outcome, not an architecture. You can achieve SSO through federation, through session cookies scoped to a single domain, or through application-level credential management. When a health system says they want SSO for your application, they typically mean they want clinicians to use existing Entra ID credentials without a separate login screen appearing.

Azure AD identity federation is the specific architecture where your application's domain delegates authentication entirely to an external identity provider, such as a health system's Entra ID tenant. The trust is explicit, standards-based, and controlled by certificate exchange. SSO is the result a clinician notices; federation is the technical contract that produces that result.

Password hash sync and pass-through authentication

Password hash sync (PHS) copies a hashed version of each user's on-premises Active Directory password into Entra ID. Authentication happens in the cloud against that hash, so users get a consistent login experience even when on-premises infrastructure is unavailable. The tradeoff is that credential data, even in hashed form, leaves the on-premises environment, and some health system security teams raise this point directly during compliance reviews.

Pass-through authentication keeps credentials entirely on-premises, which satisfies stricter data residency requirements that some health systems enforce under internal security policies.

Pass-through authentication (PTA) routes authentication requests back to on-premises agents that validate credentials against Active Directory directly. No password data leaves the local environment. For vendors building applications that health systems deploy in hybrid setups, knowing whether a health system uses PHS or PTA affects how your application handles failures when cloud-to-on-premises connectivity degrades. Federation sits above both of these options because it operates at the identity trust layer rather than at the credential synchronization layer, which is why it requires different configuration steps and carries different infrastructure dependencies than either sync method.

How to set up federation in Microsoft Entra ID

Setting up azure ad identity federation with a health system's Entra ID tenant starts with your application's registration in the Azure portal. Before you write a single line of authentication code, you need a registered application object that tells Entra ID what your app is, where to send tokens, and which permissions it needs. This registration creates the trust anchor between the health system's identity provider and your relying party, and every federation configuration step that follows builds on it.

Register your application in Entra ID

Log into the Azure portal and navigate to Microsoft Entra ID, then select App registrations and create a new registration. You will specify a display name, select the supported account types (typically single-tenant for a specific health system), and provide at least one redirect URI where Entra ID will send tokens after successful authentication. Microsoft's official documentation for app registration walks through each field in detail.

After registration, your app receives an Application (client) ID and a tenant ID. Save both values immediately, because they appear in every authentication request your application sends. You also need to configure the token type your app expects under the Authentication blade, either ID tokens for OIDC or SAML responses depending on your protocol choice.

Configure the federation trust

With your app registered, open the Token configuration section to add the claims your application needs, such as the user's email address, group memberships, or custom attributes the health system agrees to release. Confirm with the health system's IT team which claims their Entra ID tenant will include, because a mismatch between what your app expects and what the token contains causes silent authorization failures that are harder to trace than outright authentication errors.

Verifying the exact claims a health system will include in tokens before your first integration test saves significant debugging time during the security review phase.

For SAML-based federation, configure the identifier URI and reply URL under the Single sign-on blade, then download the federation metadata XML to share with the health system so they can complete their side of the trust. For OIDC, your application fetches configuration automatically from the tenant's discovery endpoint, which reduces the manual exchange steps required between your team and the health system's IT staff.

Troubleshooting, security, and availability tips

Azure AD identity federation introduces several moving parts that can fail independently, and diagnosing problems in a health system environment is harder than in a standard enterprise setting because you often don't control the identity provider directly. Knowing where failures typically occur and how to approach security and availability proactively keeps your integration stable after deployment.

Common authentication failures

Most federation failures trace back to three root causes: misconfigured redirect URIs, expired certificates, or claim mismatches between what your application expects and what the health system's Entra ID tenant actually sends. When a redirect URI in your app registration does not exactly match the URI your authentication library sends in the request, Entra ID rejects the request before the user ever authenticates. Check that match first, including trailing slashes and protocol prefixes, because the comparison is exact and case-sensitive in many configurations.

Token claim mismatches cause silent authorization failures that appear as successful logins followed immediately by access denied errors, which makes them significantly harder to diagnose than outright authentication rejections.

If users authenticate successfully but your application grants them the wrong permissions, pull the raw token using a tool like jwt.ms and compare the actual claims against what your authorization logic expects. Confirm the discrepancy with the health system's IT team and request a claim mapping adjustment on their tenant.

Securing the federation trust

Certificate rotation is the most common security gap in long-running federation setups. Entra ID automatically rotates its signing keys, and your application needs to fetch updated public keys from the tenant's OpenID Connect discovery endpoint rather than hardcoding a static certificate. Applications that cache signing keys without a refresh mechanism break silently after a key rotation. Microsoft's documentation on signing key rollover covers the exact behavior and recommended library patterns for handling it.

Conditional access policies on the health system's tenant also affect your application directly. If the health system enforces device compliance or MFA step-up requirements for specific applications, your app receives authentication failures for users who don't meet those conditions. Confirm with the health system's IT team which policies apply to your app registration before your first production deployment.

Planning for availability

Service dependencies in a federated setup mean your application's login path depends on Entra ID's availability. Monitor Microsoft's Azure Service Health dashboard and configure alerts for Entra ID outages so your support team knows immediately when authentication failures stem from the identity provider rather than your application. Build clear error messaging for users that distinguishes authentication service unavailability from application errors, which reduces support ticket volume during Entra ID incidents.

Wrap-up

Azure AD identity federation gives your application a direct path into the health system's existing identity infrastructure, which removes a major obstacle in clinical procurement conversations. You now understand how federation differs from password sync and pass-through authentication, how tokens carry claims through the authentication flow, and where configuration errors typically surface during health system reviews.

Applying this knowledge means your application arrives at a security review already aligned with what health system IT teams expect, rather than requiring remediation work after a contract is already in motion. Every detail covered here, from claim mapping to certificate rotation to conditional access compatibility, directly affects whether your integration passes review or stalls in the security queue.

If you want to skip the authentication infrastructure work entirely and deploy a fully compliant EPIC integration in weeks rather than months, see how VectorCare handles SMART on FHIR authentication for you.