-
Notifications
You must be signed in to change notification settings - Fork 0
SMART on FHIR
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.jsonSee Configuration for all SMART environment variables.
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.
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:8080Configure Siming to trust its tokens:
SMART_ISSUER=http://localhost:8091
SMART_JWKS_URL=http://localhost:8091/keysKeycloak 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.
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-configurationcontent
Siming's /.well-known/smart-configuration response passes discovery checks. The authorization flow tests require an external authorization server.
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.