Buoy Health · Authentication Profile

Buoy Health Authentication

Authentication

Buoy Health secures its APIs with oauth2 and openIdConnect across 1 declared security scheme, as derived from its OpenAPI definitions. OAuth 2.0 is offered via the authorizationCode flow(s).

symptom-checkermedical-triagedigital-healthhealthcareclinical-aicare-navigationpatient-engagementdiagnosistelehealthoauth2
Methods: oauth2, openIdConnect Schemes: 1 OAuth flows: authorizationCode API key in:

Security Schemes

Bearer oauth2
· flows: authorizationCode

Source

Authentication Profile

Raw ↑
generated: '2026-08-08'
method: searched
source: openapi/buoy-health-symptom-checker-openapi.yml
docs: https://auth.buoyhealth.com/.well-known/openid-configuration
summary:
  types:
  - oauth2
  - openIdConnect
  oauth2_flows:
  - authorizationCode
  api_key_in: []
  bearer_only: true
  scope_flat: true
  note: >-
    Every one of the 19 operations in the Symptom Checker OpenAPI inherits the single global
    `security: [{Bearer: []}]` requirement, and every operation documents a 401 response. There is no
    API-key alternative and no per-operation scope differentiation.
schemes:
- name: Bearer
  type: oauth2
  applied: global
  flows:
  - flow: authorizationCode
    authorizationUrl: https://auth.sandbox.buoyhealth.com/authorize
    tokenUrl: https://auth.sandbox.buoyhealth.com/oauth/token
    scopes: 0
  description: '[Full documentation for the Buoy Auth API is found here.](https://sandbox.buoyhealth.com/auth/redoc/)'
  sources:
  - openapi/buoy-health-symptom-checker-openapi.yml
authorization_servers:
- environment: production
  issuer: https://auth.buoyhealth.com/
  authorization_endpoint: https://auth.buoyhealth.com/authorize
  token_endpoint: https://auth.buoyhealth.com/oauth/token
  userinfo_endpoint: https://auth.buoyhealth.com/userinfo
  jwks_uri: https://auth.buoyhealth.com/.well-known/jwks.json
  revocation_endpoint: https://auth.buoyhealth.com/oauth/revoke
  registration_endpoint: https://auth.buoyhealth.com/oidc/register
  device_authorization_endpoint: https://auth.buoyhealth.com/oauth/device/code
  discovery:
  - well-known/buoy-health-openid-configuration.json
  - well-known/buoy-health-oauth-authorization-server.json
  platform: Auth0
- environment: sandbox
  issuer: https://auth.sandbox.buoyhealth.com/
  authorization_endpoint: https://auth.sandbox.buoyhealth.com/authorize
  token_endpoint: https://auth.sandbox.buoyhealth.com/oauth/token
  userinfo_endpoint: https://auth.sandbox.buoyhealth.com/userinfo
  jwks_uri: https://auth.sandbox.buoyhealth.com/.well-known/jwks.json
  revocation_endpoint: https://auth.sandbox.buoyhealth.com/oauth/revoke
  registration_endpoint: https://auth.sandbox.buoyhealth.com/oidc/register
  device_authorization_endpoint: https://auth.sandbox.buoyhealth.com/oauth/device/code
  discovery:
  - well-known/buoy-health-sandbox-openid-configuration.json
  - well-known/buoy-health-sandbox-oauth-authorization-server.json
  platform: Auth0
grant_types_supported:
- client_credentials
- authorization_code
- refresh_token
- password
- implicit
- 'urn:ietf:params:oauth:grant-type:device_code'
- 'urn:ietf:params:oauth:grant-type:token-exchange'
- 'urn:ietf:params:oauth:grant-type:jwt-bearer'
- 'http://auth0.com/oauth/grant-type/password-realm'
- 'http://auth0.com/oauth/grant-type/passwordless/otp'
- 'http://auth0.com/oauth/grant-type/mfa-oob'
- 'http://auth0.com/oauth/grant-type/mfa-otp'
- 'http://auth0.com/oauth/grant-type/mfa-recovery-code'
token_endpoint_auth_methods_supported:
- client_secret_basic
- client_secret_post
- private_key_jwt
- none
pkce:
  supported: true
  code_challenge_methods: [S256, plain]
id_token_signing_alg_values_supported: [HS256, RS256, PS256]
mfa:
  challenge_endpoint: https://auth.buoyhealth.com/mfa/challenge
  grant_types: [mfa-oob, mfa-otp, mfa-recovery-code]
observations:
- id: spec-points-at-sandbox-only
  detail: >-
    The OpenAPI's oauth2 flow hardcodes the SANDBOX authorization and token endpoints
    (auth.sandbox.buoyhealth.com) while listing both the sandbox and production API servers. A client
    generated straight from the spec will authenticate against sandbox even when calling production.
    The production issuer (auth.buoyhealth.com) is only discoverable by probing /.well-known/.
- id: empty-scopes-map
  detail: >-
    The oauth2 scheme declares an empty `scopes` map and no operation names a scope, so the spec
    conveys no least-privilege model — a token is all-or-nothing across the whole triage surface.
- id: plain-pkce-allowed
  detail: >-
    The authorization server advertises `plain` alongside `S256` in code_challenge_methods_supported.
- id: no-protected-resource-metadata
  detail: >-
    Neither API host publishes RFC 9728 oauth-protected-resource metadata, so the resource-to-issuer
    binding cannot be discovered mechanically.
x-evidence:
- url: https://auth.buoyhealth.com/.well-known/openid-configuration
  http_status: 200
  fetched: '2026-08-08'
- url: https://auth.sandbox.buoyhealth.com/.well-known/oauth-authorization-server
  http_status: 200
  fetched: '2026-08-08'
- url: https://sandbox.buoyhealth.com/auth/redoc/
  http_status: 401
  fetched: '2026-08-08'
  note: The Buoy Auth API reference the OpenAPI links to is itself credential-gated.