Skip to content

SMART on FHIR

Shinren Pan edited this page Jun 12, 2026 · 1 revision

SMART on FHIR

What Siming implements

Siming is a SMART resource server — it validates Bearer tokens issued by an external authorization server, but does not issue tokens itself.

Endpoint / Feature Status
GET /.well-known/smart-configuration — discovery
JWT Bearer token validation (Authorization: Bearer <token>)
JWKS or PEM public key loading at startup
Scope-based access control ❌ — tokens are validated but scopes are not enforced per-resource
GET /authorize — authorization endpoint
POST /token — token endpoint
PKCE (authorization_code flow)
EHR Launch / Standalone Launch
Launch context (launch/patient, launch/encounter)

Enable resource server mode by setting SMART_ISSUER:

SMART_ISSUER=https://auth.example.com
SMART_JWKS_URL=https://auth.example.com/.well-known/jwks.json

See Configuration for all SMART environment variables.


For interoperability testing (聯測)

Taiwan's FHIR interoperability testing events (and Inferno's SMART App Launch test suite) require a complete SMART on FHIR authorization server in addition to a FHIR resource server.

The practical setup is to run an authorization server alongside Siming — the two are separate services connected by configuration.

Recommended: SMART Health IT Launcher

SMART Health IT Launcher is the HL7 reference SMART authorization server, purpose-built for interoperability testing.

# docker-compose.yml addition
  smart-launcher:
    image: smartonfhir/smart-launcher-2:latest
    ports:
      - "8091:8080"
    environment:
      FHIR_SERVER_URL: http://app:8080

Configure Siming to trust its tokens:

SMART_ISSUER=http://localhost:8091
SMART_JWKS_URL=http://localhost:8091/keys

Alternative: Keycloak

Keycloak is a production-grade authorization server that supports SMART on FHIR via the Keycloak SMART on FHIR plugin. More complex to configure but suitable for production deployments.


What the Inferno SMART test suite checks

For reference, the Inferno SMART App Launch test suite (g10_certification) tests:

  • Standalone Launch with PKCE
  • EHR Launch with launch context
  • Token refresh
  • Token introspection
  • Scope negotiation (patient/*.read, user/*.write, etc.)
  • .well-known/smart-configuration content

Siming's /.well-known/smart-configuration response passes discovery checks. The authorization flow tests require an external authorization server.


Roadmap note

A built-in SMART authorization server is not currently planned for Siming. The architectural reason: authorization servers and resource servers have different scaling, security, and operational characteristics. Keeping them separate follows the SMART spec's intent and matches how HAPI FHIR and most production deployments work.

If built-in AS support becomes needed, it would be a significant addition — full OAuth2 authorization_code + client_credentials flows, PKCE, scope enforcement, and launch context binding.

Clone this wiki locally