Human Longevity Authentication

generated: '2026-08-22'
method: probed
source: https://auth.humanlongevity.com/.well-known/openid-configuration
scope: >-
  This profile describes the ONLY authentication surface Human Longevity publishes: the OpenID
  Connect authorization server that fronts the HLI client portal and mobile app. Human Longevity
  publishes no public API, no developer program and no API key issuance, so there is no
  developer-facing authentication documentation to profile. Everything below was read from the
  provider's own machine-readable discovery document, not from prose.
summary:
  public_api_authentication: none-published
  end_user_authentication: openid-connect
  provider: Auth0 (custom domain on the company's own humanlongevity.com apex)
issuer: https://auth.humanlongevity.com/
schemes:
- id: hli_portal_oidc
  type: openIdConnect
  openIdConnectUrl: https://auth.humanlongevity.com/.well-known/openid-configuration
  description: >-
    OpenID Connect / OAuth 2.0 authorization server for the Human Longevity client portal
    (portal.humanlongevity.com) and the HLI mobile app. Access is limited to HLI clinic clients;
    there is no self-service developer registration.
  endpoints:
    authorization: https://auth.humanlongevity.com/authorize
    token: https://auth.humanlongevity.com/oauth/token
    userinfo: https://auth.humanlongevity.com/userinfo
    jwks: https://auth.humanlongevity.com/.well-known/jwks.json
    revocation: https://auth.humanlongevity.com/oauth/revoke
    device_authorization: https://auth.humanlongevity.com/oauth/device/code
    dynamic_client_registration: https://auth.humanlongevity.com/oidc/register
    mfa_challenge: https://auth.humanlongevity.com/mfa/challenge
  grant_types:
  - 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
  - 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
  pkce:
    supported: true
    code_challenge_methods:
    - S256
    - plain
  token_endpoint_auth_methods:
  - client_secret_basic
  - client_secret_post
  - private_key_jwt
  - none
  id_token_signing_algs:
  - RS256
  - PS256
  - HS256
  mfa:
    supported: true
    evidence: >-
      mfa_challenge_endpoint and the four http://auth0.com/oauth/grant-type/mfa-* grant types are
      advertised in the discovery document.
  audiences_observed:
  - https://client-portal.hli.com
  audience_note: >-
    Read from the Auth0 SDK configuration embedded in the portal's own main.js bundle
    (https://portal.humanlongevity.com/main.aac5aadc52a10f4b.js). This is an OAuth audience
    identifier for the portal's private backend API. That backend publishes no contract and no
    documentation, and the hli.com host that the identifier is named after does not resolve to a
    Human Longevity property, so it is recorded as an identifier only — never as a callable base URL.
observations:
- id: weak_algs_advertised
  note: >-
    HS256 is advertised alongside RS256/PS256 for ID token signing, and `plain` alongside S256 for
    PKCE. Both are Auth0 tenant defaults rather than deliberate HLI choices, but a public agent
    reading this discovery document cannot tell the difference.
- id: no_oauth_protected_resource
  note: >-
    /.well-known/oauth-protected-resource returns 404, so there is no RFC 9728 resource metadata
    pointing at a protected API.