Flume Health · Authentication Profile

Flume Health Authentication

Authentication

Flume Health secures its APIs with oauth2 and openIdConnect across 3 declared security schemes, as derived from its OpenAPI definitions. OAuth 2.0 is offered via the implicit, authorization_code, client_credentials, refresh_token, device_code, and token_exchange flow(s).

healthcarehealth-planspayershealthcare-datadata-integrationipaaseligibilityclaimsknowledge-graphmcpagent-nativeoauth2data-engineeringinteroperability
Methods: oauth2, openIdConnect Schemes: 3 OAuth flows: implicit, authorization_code, client_credentials, refresh_token, device_code, token_exchange API key in:

Security Schemes

OAuth2Implicit oauth2
· flows: implicit
Flume authorization server (live) openIdConnect
MCP protected resource oauth2

Source

Authentication Profile

Raw ↑
generated: '2026-08-16'
method: probed
source: >-
  https://auth.flumehealth.com/.well-known/oauth-authorization-server +
  https://console.flumehealth.com/.well-known/oauth-protected-resource + openapi/flume-health-console-api-openapi.yml
note: >-
  Upgraded from the spec-only derivation. The Flume Console API's Swagger 2.0 contract declares exactly one security
  scheme — an OAuth 2.0 implicit flow — which understates what is actually deployed. The live authorization server
  at auth.flumehealth.com (an Auth0 tenant on Flume's own domain, issuer https://auth.flumehealth.com/) publishes
  RFC 8414 / OIDC discovery metadata advertising 13 grant types including authorization_code with PKCE,
  client_credentials, refresh_token, device_code and token exchange, plus dynamic client registration and DPoP.
  Machine-to-machine integrators should use those, not the implicit flow in the spec. Flume publishes no
  authentication documentation page — there is nothing to search — so every fact below comes from the contract or
  from a live probe.
summary:
  types:
  - oauth2
  - openIdConnect
  oauth2_flows:
  - implicit
  - authorization_code
  - client_credentials
  - refresh_token
  - device_code
  - token_exchange
  primary: OAuth 2.0 bearer token in the Authorization header
  api_keys: false
  mutual_tls: false
  basic_auth: false
docs: null
docs_note: Flume publishes no public authentication guide. The only machine-readable auth description is the securityDefinitions block in the contract plus the discovery documents below.

schemes:
- name: OAuth2Implicit
  type: oauth2
  declared_in: openapi/flume-health-console-api-openapi.yml
  flows:
  - flow: implicit
    authorizationUrl: https://auth.flumehealth.com/authorize?audience=https://console.flumehealth.com/api
    scopes:
    - openid
    - profile
    - email
  note: The browser flow the Flume Console itself uses. It is the ONLY scheme the published contract declares.
  sources:
  - openapi/flume-health-console-api-openapi.yml

- name: Flume authorization server (live)
  type: openIdConnect
  declared_in: https://auth.flumehealth.com/.well-known/openid-configuration
  issuer: https://auth.flumehealth.com/
  endpoints:
    authorization: https://auth.flumehealth.com/authorize
    token: https://auth.flumehealth.com/oauth/token
    userinfo: https://auth.flumehealth.com/userinfo
    jwks: https://auth.flumehealth.com/.well-known/jwks.json
    registration: https://auth.flumehealth.com/oidc/register
    revocation: https://auth.flumehealth.com/oauth/revoke
    device_authorization: https://auth.flumehealth.com/oauth/device/code
    end_session: https://auth.flumehealth.com/oidc/logout
    backchannel_authentication: https://auth.flumehealth.com/bc-authorize
    mfa_challenge: https://auth.flumehealth.com/mfa/challenge
  grant_types_supported:
  - authorization_code
  - client_credentials
  - refresh_token
  - implicit
  - password
  - 'urn:ietf:params:oauth:grant-type:device_code'
  - 'urn:ietf:params:oauth:grant-type:token-exchange'
  - 'urn:ietf:params:oauth:grant-type:jwt-bearer'
  code_challenge_methods_supported:
  - S256
  - plain
  token_endpoint_auth_methods_supported:
  - client_secret_basic
  - client_secret_post
  - private_key_jwt
  - none
  id_token_signing_alg_values_supported:
  - RS256
  - PS256
  - HS256
  dpop_signing_alg_values_supported:
  - ES256
  dynamic_client_registration: true
  mfa: true
  sources:
  - well-known/flume-health-oauth-authorization-server.json
  - well-known/flume-health-openid-configuration.json

- name: MCP protected resource
  type: oauth2
  declared_in: https://console.flumehealth.com/.well-known/oauth-protected-resource
  resource: https://console.flumehealth.com/api/v1/context/mcp
  authorization_servers:
  - https://auth.flumehealth.com
  bearer_methods_supported:
  - header
  scopes_supported:
  - openid
  - profile
  - email
  - offline_access
  rfc9728: true
  note: >-
    Correct RFC 9728 implementation — the MCP endpoint answers an anonymous JSON-RPC POST with HTTP 401 and
    WWW-Authenticate Bearer carrying a resource_metadata pointer back to this document.
  sources:
  - well-known/flume-health-oauth-protected-resource.json

authorization_context:
  account_scoping_header: X-Flume-Account-ID
  required_on: 122 of 153 operations
  note: >-
    Bearer authentication alone is not sufficient. Nearly every operation additionally requires the
    X-Flume-Account-ID header naming the health-plan account. Missing or wrong values surface as 403.

evidence:
- url: https://auth.flumehealth.com/.well-known/oauth-authorization-server
  http_status: 200
- url: https://auth.flumehealth.com/.well-known/openid-configuration
  http_status: 200
- url: https://auth.flumehealth.com/.well-known/jwks.json
  http_status: 200
- url: https://console.flumehealth.com/.well-known/oauth-protected-resource
  http_status: 200
- url: https://console.flumehealth.com/api/v1/accounts
  http_status: 401
  detail: bare request rejected; no WWW-Authenticate on the REST path (unlike the MCP path, which does send one)
- url: https://console.flumehealth.com/api/docs/docs.json
  http_status: 200
checked: '2026-08-16'