SMART Backend Services lets a trusted service, with no user present, get FHIR access. The client registers a public key, signs a one time JWT, and exchanges it for a short lived access token with system scopes. Refresh tokens should not be issued. Everything runs over TLS 1.2 or later.
When to use it
The spec describes this flow for autonomous or semi-autonomous clients that access FHIR data under access the server has already approved. Typical cases are reporting jobs, data pipelines and bulk export clients. If a human launches the app, use the interactive flow instead. See SMART app launch.
The four steps
- Registration. One time, possibly out of band. The client follows the steps in the client-confidential-asymmetric profile, which covers communicating public keys. The client must register before running.
- Discovery. GET
.well-known/smart-configurationto find the token endpoint. - Token request. POST form encoded data to the token endpoint with grant_type set to client_credentials, client_assertion_type set to the JWT bearer URN, a client_assertion that is a signed, one time use JWT, and the requested scope.
- API calls. Use the returned token in an Authorization: Bearer header.
The spec says the client must be capable of protecting its authentication credential. The private key is the crown jewel here, so keep it in a secrets manager or hardware backed store, not in a repository.
Token response rules
A valid response holds access_token, token_type bearer, expires_in and scope. The recommended expires_in is 300 seconds, and the spec says it should not exceed 300. The granted scope may differ from what was requested, so the client must check it. The spec says refresh tokens should not be issued. A client simply asks for a new token when needed.
Note that the five minute figure applies to the access token. This page of the spec does not set a limit for the assertion's own expiry. It defers JWT validation rules to the client-confidential-asymmetric profile, so check that profile for assertion claims.
System scopes
Backend Services uses system/ scopes, for example system/Observation.rs. Using user/ or patient/ scopes is not prohibited, but it needs out of band coordination to establish context.
A safety rule for references
If a returned resource references another server, the client should not blindly follow it or send its token there. This stops a data driven redirect from leaking a valid token.
Hardening checklist
- One key pair per client and environment.
- Rotate keys and publish a key set the server can fetch, if the registration profile supports it.
- Request only the system scopes the job needs.
- Log every token request and the scope granted.
- Never send the bearer token to hosts outside the FHIR base you were authorized for.
Quick check
Why no refresh token?
The client can always authenticate again with its signed assertion, so a long lived refresh token adds risk without benefit. The spec says refresh tokens should not be issued.
Sources
Last reviewed: 19 October 2026.
