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

Raw ↑
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.