Canvas Medical · Authentication Profile
Canvas Medical Authentication
Authentication
Canvas Medical secures its APIs with oauth2, http, and openIdConnect across 3 declared security schemes, as derived from its OpenAPI definitions. OAuth 2.0 is offered via the authorizationCode, clientCredentials, and refreshToken flow(s).
EHRFHIRHealthcareElectronic Health RecordsVirtual CareClinical WorkflowsPatient ManagementCare Coordination
Methods: oauth2, http, openIdConnect
Schemes: 3
OAuth flows: authorizationCode, clientCredentials, refreshToken
API key in:
Security Schemes
OAuth2ClientCredentials oauth2
· flows: clientCredentials
OAuth2AuthCode oauth2
· flows: authorizationCode
BearerAuth http
scheme: bearer
Source
Authentication Profile
generated: '2026-08-14'
method: searched
source: openapi/canvas-medical-fhir-api-openapi.yml
docs: https://docs.canvasmedical.com/api/customer-authentication/
also:
- https://docs.canvasmedical.com/api/authentication-best-practices/
- https://docs.canvasmedical.com/api/developer-access/
- https://fumage-apex.canvasmedical.com/.well-known/smart-configuration
- https://apex.canvasmedical.com/auth/.well-known/openid-configuration
note: >-
Upgraded from derived to searched on 2026-08-14 against the Canvas docs and two live discovery
documents on a production instance. Canvas is itself an OAuth 2.0 authorization server, one per
customer instance — there is no central IdP shared across customers.
summary:
types: [oauth2, http, openIdConnect]
oauth2_flows: [authorizationCode, clientCredentials, refreshToken]
api_key_in: []
pkce: [S256]
bearer_format: JWT
standard: SMART App Launch (SMART on FHIR) over OAuth 2.0 + OIDC
authorization_server:
model: one authorization server per customer instance
issuer_pattern: https://{canvas-instance}.canvasmedical.com
token_endpoint: https://{canvas-instance}.canvasmedical.com/auth/token/
authorization_endpoint: https://{canvas-instance}.canvasmedical.com/auth/authorize/
application_registration: https://{canvas-instance}.canvasmedical.com/auth/applications/
jwks_uri: https://{canvas-instance}.canvasmedical.com/auth/.well-known/jwks.json
smart_configuration: https://fumage-{canvas-instance}.canvasmedical.com/.well-known/smart-configuration
openid_configuration: https://{canvas-instance}.canvasmedical.com/auth/.well-known/openid-configuration
discovery_verified: '2026-08-14'
discovery_http_status: 200
schemes:
- name: OAuth2ClientCredentials
type: oauth2
flows:
- flow: clientCredentials
tokenUrl: https://{canvas-instance}.canvasmedical.com/auth/token/
scopes: 8
description: >-
Machine-to-machine authentication using the client credentials grant, for daemons, CLIs and
server-side integrations. Register a Confidential client at {instance}/auth/applications/ and use
the resulting client_id/client_secret.
request: >-
POST {instance}/auth/token/ with Content-Type: application/x-www-form-urlencoded and
grant_type=client_credentials, client_id, client_secret.
scope_behaviour: >-
Scopes are optional; when omitted the token carries the OAuth application's configured allowed
scopes.
patient_scoped_variant: >-
Adding patient=<id> plus explicit patient/ scopes to the same request yields a patient-scoped
token. Omitting scope, or requesting invalid scopes, is rejected.
sources: [openapi/canvas-medical-fhir-api-openapi.yml, docs]
- name: OAuth2AuthCode
type: oauth2
flows:
- flow: authorizationCode
authorizationUrl: https://{canvas-instance}.canvasmedical.com/auth/authorize/
tokenUrl: https://{canvas-instance}.canvasmedical.com/auth/token/
scopes: 3
description: >-
User-delegated access for web and native applications. The access token carries the identity of
the authorizing user, so FHIR calls are scoped to that user's permissions and SimpleAPI plugin
endpoints receive them as the event actor.
pkce: S256
hard_requirements:
- >-
Staff (user/) launches MUST include a `launch` query parameter holding a base64-encoded JSON
context object, e.g. {"patient":""} -> eyJwYXRpZW50IjoiIn0=. Without it the authorization is
denied with error=access_denied.
- Scopes are required in the authorize URL; encode "/" as %2F and the separator space as %20.
- The authorization code is valid for approximately 60 seconds — exchange it immediately.
sources: [openapi/canvas-medical-fhir-api-openapi.yml, docs]
- name: BearerAuth
type: http
scheme: bearer
bearerFormat: JWT
description: >-
All API calls present the token as `Authorization: Bearer <access_token>` — both the FHIR API
({FUMAGE_BASE_URL}/Patient) and SimpleAPI plugin endpoints
({instance}/plugin-io/api/{plugin_name}/{endpoint}).
sources: [openapi/canvas-medical-fhir-api-openapi.yml, docs]
tokens:
access_token:
ttl_seconds: 36000
ttl_human: 10 hours
type: Bearer
reuse_guidance: >-
"You can and should reuse access tokens to reduce the number of tokens that are valid at any
given time."
refresh_token:
expires: false
single_use: true
behaviour: >-
Each refresh consumes the old refresh token and returns a NEW one, which must be stored. The
scope parameter on refresh must match the original grant or be a subset.
requested_by: offline_access scope
authorization_code:
ttl_seconds: 60
patient_scoped_token_response_fields:
- access_token
- expires_in
- token_type
- scope
- smart_style_url
- patient
- need_patient_banner
access_gate:
self_serve: false
note: >-
Registering an application is only possible once you have access to an instance. Third-party
developers request access at developer-access@canvasmedical.com; authenticity verification
completes within 10 business days and production enablement within 5 more (45 CFR 170.404). No
fees, no exclusivity, no reciprocal data access.
models:
- name: patient-directed
authorized_by: the individual patient, via the SMART authorization-code flow
context: patient/
- name: population / bulk
authorized_by: the practice or organization holding the data
context: system/
note: typically client credentials plus bulk export
platform_identity:
sso: SAML supported for EHR users; where SSO is used, password policy, MFA, session lifetime and account lifecycle are governed by the customer's IdP.
fallback: Canvas-managed credentials validate minimum length, similarity to name/username, all-numeric values and a common-password list.
lockout: Failed-login lockout applies to interactive sessions on either path.
authorization: RBAC with model permissions (record types) and object permissions (specific records, scoped by patient group), administered through roles and groups.
source: https://docs.canvasmedical.com/guides/platform-security-overview/
cross_ref:
scopes: scopes/canvas-medical-scopes.yml
conventions: conventions/canvas-medical-conventions.yml
well_known: well-known/canvas-medical-well-known.yml