generated: '2026-08-15'
method: probed
source: >-
  https://auth.clarifyhealth.com/.well-known/openid-configuration and
  https://okta.clarifyhealth.com/.well-known/openid-configuration (both HTTP 200,
  fetched 2026-08-15)
scope_of_this_document: >-
  Clarify Health publishes no public API and no developer authentication guide. What it
  does publish, anonymously and machine-readably, are two OpenID Connect discovery
  documents on hosts it controls. They describe how a human or a machine authenticates
  INTO the Clarify Atlas / Meridian platform — they are not the authentication profile of
  a product API, because no product API is published. Everything below is read verbatim
  from those two documents; nothing is inferred.
providers:
- name: Auth0 tenant (customer + workforce sign-in)
  issuer: https://auth.clarifyhealth.com/
  discovery: https://auth.clarifyhealth.com/.well-known/openid-configuration
  file: ../well-known/clarify-health-auth-openid-configuration.json
  http_status: 200
  endpoints:
    authorization: https://auth.clarifyhealth.com/authorize
    token: https://auth.clarifyhealth.com/oauth/token
    userinfo: https://auth.clarifyhealth.com/userinfo
    jwks: https://auth.clarifyhealth.com/.well-known/jwks.json
    revocation: https://auth.clarifyhealth.com/oauth/revoke
    registration: https://auth.clarifyhealth.com/oidc/register
    device_authorization: https://auth.clarifyhealth.com/oauth/device/code
    backchannel_authentication: https://auth.clarifyhealth.com/bc-authorize
    mfa_challenge: https://auth.clarifyhealth.com/mfa/challenge
  schemes:
  - type: openIdConnect
    name: OpenID Connect
    id_token_signing: [HS256, RS256, PS256]
  - type: oauth2
    flows: [authorization_code, client_credentials, refresh_token, password, implicit, device_code, token_exchange, jwt_bearer]
    note: >-
      client_credentials is advertised, which means machine-to-machine tokens are issuable
      against this tenant — but no resource server / audience is publicly documented.
  pkce:
    supported: true
    methods: [S256, plain]
    note: '"plain" is still advertised alongside S256.'
  token_endpoint_auth_methods: [client_secret_basic, client_secret_post, private_key_jwt, none]
  mfa: true
  dpop:
    supported: true
    algs: [ES256]
  backchannel_logout: true
  scopes_supported: [openid, profile, offline_access, name, given_name, family_name, nickname,
    email, email_verified, picture, created_at, identities, phone, address]
  note: >-
    Only standard OIDC identity scopes are advertised. There are no Clarify-specific
    resource scopes in the discovery document, which is consistent with there being no
    published product API to scope.
- name: Okta org authorization server
  issuer: https://okta.clarifyhealth.com
  discovery: https://okta.clarifyhealth.com/.well-known/openid-configuration
  file: ../well-known/clarify-health-okta-openid-configuration.json
  http_status: 200
  endpoints:
    authorization: https://okta.clarifyhealth.com/oauth2/v1/authorize
    token: https://okta.clarifyhealth.com/oauth2/v1/token
    userinfo: https://okta.clarifyhealth.com/oauth2/v1/userinfo
    jwks: https://okta.clarifyhealth.com/oauth2/v1/keys
    introspection: https://okta.clarifyhealth.com/oauth2/v1/introspect
    revocation: https://okta.clarifyhealth.com/oauth2/v1/revoke
    end_session: https://okta.clarifyhealth.com/oauth2/v1/logout
    registration: https://okta.clarifyhealth.com/oauth2/v1/clients
    device_authorization: https://okta.clarifyhealth.com/oauth2/v1/device/authorize
    pushed_authorization_request: https://okta.clarifyhealth.com/oauth2/v1/par
  schemes:
  - type: openIdConnect
    name: OpenID Connect
    id_token_signing: [RS256]
    id_token_encryption:
      alg: [RSA-OAEP-256, RSA-OAEP-384, RSA-OAEP-512]
      enc: [A256GCM]
  - type: oauth2
    flows: [authorization_code, implicit, refresh_token, password, device_code, ciba, okta_otp, okta_oob]
  pkce:
    supported: true
    methods: [S256]
    note: S256 only — no "plain" downgrade.
  token_endpoint_auth_methods: [client_secret_basic, client_secret_post, client_secret_jwt,
    private_key_jwt, none]
  par: true
  dpop:
    supported: true
    algs: [RS256, RS384, RS512, ES256, ES384, ES512]
  scopes_supported: [openid, email, profile, address, phone, offline_access, groups]
  custom_authorization_servers:
    public: false
    note: >-
      /oauth2/default/.well-known/openid-configuration returns 401 E0000015, so any
      Clarify-specific API scopes that exist on a custom authorization server are not
      anonymously discoverable.
api_keys:
  documented: false
  note: No public API key issuance, key prefix, or credential documentation was found.
mutual_tls:
  documented: false
findings:
- Two independent identity providers are live for one company (Auth0 for the platform, Okta
  for the org) — a normal split, but consumers of a future Clarify API would need to be
  told which issuer is authoritative.
- Both issuers advertise DPoP, PKCE, and dynamic client registration; neither publishes a
  resource-server audience, so there is no way for an outside integrator to obtain a token
  that is good for anything.
- The Auth0 tenant still advertises the deprecated `password` and `implicit` grants and
  `plain` PKCE.