Commure · Authentication Profile
Commure Authentication
Authentication
Commure secures its APIs with http and oauth2 across 2 declared security schemes, as derived from its OpenAPI definitions. OAuth 2.0 is offered via the authorizationCode and clientCredentials flow(s).
HealthcareUnited StatesClinical AIAmbient AIRevenue Cycle ManagementFHIRSMART on FHIRInteroperabilityEHRRemote MonitoringHealth SystemTerminology Services
Methods: http, oauth2
Schemes: 2
OAuth flows: authorizationCode, clientCredentials
API key in:
Security Schemes
SMARTonFHIR oauth2
· flows: authorizationCode, clientCredentials
bearerAuth http
scheme: bearer
Source
Authentication Profile
generated: '2026-08-15'
method: searched
source: openapi/commure-fhir-openapi.yml
docs: https://www.postman.com/commure/commure/documentation/vp76tv7/commure-fhir-api
also_probed:
- https://accounts.commure.com/.well-known/openid-configuration
- https://accounts.commure.com/.well-known/oauth-authorization-server
- https://accounts.commure.com/oauth2/default/.well-known/openid-configuration
summary:
types:
- http
- oauth2
oauth2_flows:
- authorizationCode
- clientCredentials
schemes:
- name: SMARTonFHIR
type: oauth2
flows:
- flow: authorizationCode
authorizationUrl: https://api-{tenant-id}.developer.commure.com/auth/authorize
tokenUrl: https://api-{tenant-id}.developer.commure.com/auth/token
scopes: 5
- flow: clientCredentials
tokenUrl: https://api-{tenant-id}.developer.commure.com/auth/token
scopes: 0
description: OpenID Connect / SMART App Launch. Supports the authorization code (with PKCE),
implicit, hybrid, client credentials and refresh token grants.
sources:
- openapi/commure-fhir-openapi.yml
- name: bearerAuth
type: http
scheme: bearer
description: Access token issued by the Commure Authentication API, presented as a bearer
token (tokens are prefixed "Sec-").
sources:
- openapi/commure-fhir-openapi.yml
token:
type: bearer
header: Authorization
format: 'Bearer Sec-...'
prefix: Sec-
grants:
- authorization_code
- client_credentials
- refresh_token
extras:
pkce: true
implicit_flow_supported: true
hybrid_flow_supported: true
smart_ehr_launch: true
smart_standalone_launch: true
sso: >-
The authorize endpoint authenticates the user via single sign-on, typically using an SSO
provider configured by the hospital.
endpoints:
authorize: /auth/authorize
token: /auth/token
userinfo: /auth/userinfo
jwks: /auth/jwks
logout: /auth/logout
openid_configuration: /auth/.well-known/openid-configuration
smart_configuration: /api/v1/r4/.well-known/smart-configuration
tenancy:
model: host-scoped
note: >-
The tenant id is part of the host (api-{tenant-id}.developer.commure.com), so a token is
scoped to a single tenant host. Commure's own example tenant id is 99750511.
identity_provider:
scope: >-
This block describes the LIVE identity surface for Commure's PRODUCTS (the accounts.commure.com
sign-in already linked from apis.yml). It is a separate surface from the FHIR API auth
described above, which lives on the retired tenant hosts. It is recorded here because it is the
only Commure authentication endpoint that is currently reachable and machine-readable.
host: accounts.commure.com
platform: Okta Customer Identity (Okta-hosted, on Commure's own domain)
method: probed
probed: '2026-08-15'
issuers:
- issuer: https://accounts.commure.com
metadata:
- path: /.well-known/openid-configuration
status: 200
file: well-known/commure-accounts-openid-configuration.json
spec: OpenID Connect Discovery 1.0
- path: /.well-known/oauth-authorization-server
status: 200
file: well-known/commure-accounts-oauth-authorization-server.json
spec: RFC 8414 OAuth 2.0 Authorization Server Metadata
endpoints:
authorization: https://accounts.commure.com/oauth2/v1/authorize
token: https://accounts.commure.com/oauth2/v1/token
userinfo: https://accounts.commure.com/oauth2/v1/userinfo
jwks: https://accounts.commure.com/oauth2/v1/keys
introspection: https://accounts.commure.com/oauth2/v1/introspect
revocation: https://accounts.commure.com/oauth2/v1/revoke
registration: https://accounts.commure.com/oauth2/v1/clients
device_authorization: https://accounts.commure.com/oauth2/v1/device/authorize
end_session: https://accounts.commure.com/oauth2/v1/logout
- issuer: https://accounts.commure.com/oauth2/default
role: Commure's custom authorization server - the one carrying Commure-configured scopes.
metadata:
- path: /oauth2/default/.well-known/openid-configuration
status: 200
file: well-known/commure-accounts-default-openid-configuration.json
spec: OpenID Connect Discovery 1.0
endpoints:
authorization: https://accounts.commure.com/oauth2/default/v1/authorize
token: https://accounts.commure.com/oauth2/default/v1/token
userinfo: https://accounts.commure.com/oauth2/default/v1/userinfo
jwks: https://accounts.commure.com/oauth2/default/v1/keys
introspection: https://accounts.commure.com/oauth2/default/v1/introspect
revocation: https://accounts.commure.com/oauth2/default/v1/revoke
end_session: https://accounts.commure.com/oauth2/default/v1/logout
grants:
- authorization_code
- implicit
- refresh_token
- password
- client_credentials
- 'urn:ietf:params:oauth:grant-type:device_code'
grants_note: >-
client_credentials is advertised only by the org authorization server
(/.well-known/oauth-authorization-server); the custom `default` server does not list it. The
urn:okta:* and auth0.com MFA grant types in the raw documents are Okta platform grants and are
not restated here.
response_types: [code, token, id_token, code id_token, code token, id_token token, code id_token token]
pkce: true
code_challenge_methods: [S256]
token_endpoint_auth_methods: [client_secret_basic, client_secret_post, client_secret_jwt, private_key_jwt, none]
private_key_jwt: true
dpop: true
dpop_algorithms: [RS256, RS384, RS512, ES256, ES384, ES512]
dynamic_client_registration: true
dynamic_client_registration_note: >-
A registration_endpoint is advertised (/oauth2/v1/clients). This is standard Okta org behaviour
and is almost certainly access-token protected; it was not exercised.
caveat: >-
This is a delegated identity provider. It authenticates humans into Commure's product estate;
it is NOT an authorization server for a public Commure API, and no Commure API resource server
advertises it (/.well-known/oauth-protected-resource returns 405 here). Do not read it as a
developer-facing API auth surface.
x-searched:
fetched: '2026-08-15'
previous: '2026-07-31'
sources:
- https://www.postman.com/commure/commure/documentation/vp76tv7/commure-fhir-api
- postman/commure-fhir-api-collection.json
findings:
- Commure publishes no standalone authentication documentation page; the auth contract above
is taken from the request descriptions in its public Postman collection.
- Access is gated by the Commure Developer User Agreement - credentials are issued under a
partner/approval relationship, not self-serve.
- Neither discovery document (/auth/.well-known/openid-configuration,
/api/v1/r4/.well-known/smart-configuration) is currently served by any reachable host; see
well-known/commure-well-known.yml.