.png)
The debates running through MCP authorization right now, how a client discovers the authorization server, how a token gets bound to one resource, how scopes should map to capabilities, were all settled once before, in healthcare, starting more than a decade ago. SMART on FHIR is what OAuth looks like after a regulated industry spent years hardening delegated third-party access. MCP is speedrunning the same road. The overlaps are worth studying.
SMART on FHIR clients do not copy OAuth endpoints out of developer documentation. They ask the FHIR server itself: the capability statement at /metadata (and the newer .well-known/smart-configuration) publishes the authorize and token endpoints. MCP landed on the same shape with protected resource metadata (RFC 9728): the resource tells the client where its authorization server lives. Same lesson, twelve years apart: configuration that lives in docs drifts; configuration served by the resource stays true.
SMART requires a static aud parameter on the authorize URL naming the FHIR server the token is for, so an authorization granted against one hospital's system cannot be replayed against another's. MCP's answer is resource indicators (RFC 8707): the token request names the MCP server the token is bound to. Different spec, identical threat model.
SMART scopes are structured: patient/MedicationRequest.read encodes the context (patient-level or user-level), the clinical resource, and the access mode in one string. It makes a consent screen legible and an authorization decision auditable. MCP scopes today are looser, often per-server conventions. As MCP servers expose more destructive capabilities, expect pressure toward exactly this kind of grammar: a scope a reviewer can read and reason about. Scope-per-tool authorization on MCP servers is already the pattern security teams ask for.
SMART's fhirUser claim ties a token to the clinician or patient who authorized it, which is what makes per-user audit trails possible in EHR integrations. MCP deployments are converging on the same requirement from the agent side: enterprises want every tool call attributable to the person whose authority the agent carries, not to a shared client credential. Delegated agent authentication is this exact idea generalized beyond healthcare.
SMART on FHIR treats long-lived access as something the user explicitly grants, not something the client assumes. Access tokens are short-lived. If an application wants to keep acting after the session ends, it requests the offline_access scope, and that request is visible in the authorization: the user is consenting specifically to persistence. An app that only needs access while the user is present requests online_access instead, and its authority expires with the session.
MCP guidance is converging on the same posture, short-lived access tokens with refresh flows, but the healthcare lesson worth importing is the visibility: persistence as a named, consentable thing rather than a default. Agents are exactly the kind of client that wants standing access, which is exactly why the grant should be explicit. An enterprise reviewing an agent deployment should be able to see, in the scope list, whether the agent's authority survives the user walking away.
A scope grammar is not only for machines. When permissions are structured, patient/MedicationRequest.read rather than an opaque blob, the consent screen can say what is actually being granted: read this patient's medications, not write them, not read everything. Healthcare needed that legibility because the person clicking approve is a clinician or a patient, not a developer.
MCP consent today is frequently all-or-nothing at the server level: authorize the server, get every tool on it. The pressure toward finer grain is already visible in practice, scoped tool subsets, per-team endpoints, action-level policies, because enterprise security teams ask the same question patients do: what exactly am I approving? Protocols earn trust when the consent screen and the enforcement boundary are the same thing.
Client onboarding. MCP supports Dynamic Client Registration and CIMD-style client identity, so a new client can register with an authorization server programmatically. SMART on FHIR has no equivalent at scale: shipping a healthcare app still means manual registration in each vendor's app program, one of the slowest parts of any EHR integration. Healthcare's uniformity came from statute; MCP's is emerging from convention and reference implementations, and on this axis the newer protocol moves faster.
Two more SMART decisions look prescient from where MCP stands.
Context as a protocol concept. SMART distinguishes launch contexts: a standalone launch initiated by the app carries different assumptions from an EHR launch initiated inside the hospital's own software, mid-patient-chart. The protocol names the difference instead of leaving it to convention. Agent sessions have the same shape, an agent acting in an interactive session versus autonomously on a schedule, and today MCP leaves that distinction to the implementer. A protocol-level notion of session context would give authorization servers something real to reason about.
Uniformity through a forcing function. SMART's consistency came from regulation: every certified EHR implements the same discovery document, the same scope grammar, the same launch flows, because the alternative is a fine. MCP has no regulator and will not get one, so its uniformity has to come from reference implementations and the gateways that sit in front of servers. That puts real weight on the middle layer: when individual servers diverge, the gateway is where consistent discovery, scoping, and audit get enforced anyway.
An agent product in healthcare ends up on both sides of this comparison at once: consuming EHR data through SMART on FHIR, and exposing or consuming tools over MCP. The protocols rhyme because the problem is the same, a third party acting on sensitive data as a specific user, with proof. Scalekit ships both halves: SMART on FHIR connectors for any certified EHR and OAuth 2.1 authorization for MCP servers, on one delegated-identity model.
SMART on FHIR is HL7's OAuth 2.0-based authorization framework that lets third-party applications act on clinical data as a specific authorized user, uniform across every certified US EHR.
MCP's OAuth 2.1 guidance uses resource indicators (RFC 8707) so a token is issued for a specific MCP server, the same audience-binding idea SMART enforces with the static aud parameter on the authorize URL. Both prevent a token granted for one server from being replayed against another.
Client onboarding. MCP supports Dynamic Client Registration and CIMD-style client identity, so a client can register programmatically. SMART on FHIR still relies on manual per-vendor app registration programs, which is one of the slowest parts of shipping a healthcare integration.
Protocol design is cheaper to borrow than to rediscover. SMART on FHIR already paid for the lessons: discovery from the resource, audience-bound tokens, legible scopes, user-tied identity. If you are building on MCP and wondering which auth decisions will matter in two years, healthcare already wrote the answer key. Building either half? Talk to us.
