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