ProofDraw · Authentication Profile

Proofdraw Authentication

Authentication

ProofDraw secures its APIs with http across 1 declared security scheme, as derived from its OpenAPI definitions.

RandomnessProvably Fairdrandverifiable-randomnessCryptographyrafflegiveawaySweepstakesLotteryVerificationWebhookREST API
Methods: http Schemes: 1 OAuth flows: API key in:

Security Schemes

bearerAuth http
scheme: bearer

Source

Authentication Profile

Raw ↑
generated: '2026-08-11'
method: searched
source: openapi/proofdraw-api-openapi.yml
docs: https://proofdraw.com/api
summary:
  types:
    - http
  http_schemes:
    - bearer
  api_key_in: []
  oauth2_flows: []
  note: >-
    Single-mechanism auth: a static, long-lived API key presented as an HTTP bearer token. No OAuth 2.0,
    no OIDC, no mTLS, so there is no scope surface to capture (scopes/ is correctly absent).
schemes:
  - name: bearerAuth
    type: http
    scheme: bearer
    description: 'API key: `Authorization: Bearer pd_live_…` (or `pd_test_…` for sandbox keys).'
    sources:
      - openapi/proofdraw-api-openapi.yml
key_model:
  prefixes:
    - prefix: pd_live_
      mode: live
    - prefix: pd_test_
      mode: sandbox
  issuance:
    - operation: POST /v1/auth/register
      description: >-
        Creates a TIER_FREE account and returns a freshly-issued pd_live_ key. Requires name, email,
        password (8–255 chars) and a `terms_accepted_at` ISO-8601 timestamp at or after the current Terms
        effective date — server-side consent enforcement, not just a frontend checkbox.
    - operation: POST /v1/auth/login
      description: >-
        Exchanges email + password for a NEW key on every call. Previously issued keys keep working;
        there is no documented key-revocation or key-listing endpoint.
  storage: >-
    Keys are hashed with SHA-256 at rest; only the prefix (e.g. `pd_live_8K3Q`) is recoverable for
    display. The raw key is returned exactly once, on the issuing response.
  passwords: bcrypt at rest, never returned
  rotation:
    documented: false
    note: >-
      Login mints a new key without invalidating prior ones, so rotation is additive-only. No revoke,
      list, or expire endpoint is published — an operator cannot retire a leaked key through the API.
unauthenticated_surface:
  - GET /health
  - GET /list/{hash}
  - GET /list/{hash}/ots
  - GET /v/{publicId}   # human-facing verification receipt; documented but absent from the OpenAPI
  - POST /v1/auth/login
  - POST /v1/auth/register
gaps:
  - No key revocation, expiry, or listing endpoint is documented.
  - No scoped or least-privilege keys — one key carries the whole account surface.
  - No OAuth 2.0 / OIDC, so no delegated third-party access model.