Quandela · Authentication Profile

Quandela Authentication

Authentication

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

Quantum ComputingPhotonic QuantumPhotonicsSingle Photon SourcesQuantum HardwareQuantum CloudQPUPercevalPython SDKQuantum Random Number GenerationQuantum SimulationVariational Quantum AlgorithmsQuantum ChemistryGraph AlgorithmsJob OrchestrationOpen-SourceFrance
Methods: http Schemes: 1 OAuth flows: API key in:

Security Schemes

BearerAuth http
scheme: bearer · in: header ()

Source

Authentication Profile

Raw ↑
generated: '2026-08-17'
method: searched
source: >-
  https://api.cloud.quandela.com/openapi.json (info.description authentication
  section, tag descriptions, components.securitySchemes, per-operation 401
  response descriptions), plus live anonymous 401 probes of
  https://api.cloud.quandela.com on 2026-08-17
docs: https://api.cloud.quandela.com/api/docs/
docs_readable: false
docs_note: >-
  The API-reference UI at https://api.cloud.quandela.com/api/docs/ 302-redirects
  to https://account.quandela.com/login?callback=... — the rendered
  documentation is behind a login. The OpenAPI document itself is served
  anonymously at the API host root, so the specification is the only publicly
  readable normative description of authentication on this API. Everything below
  is quoted from it or observed on a live response.
summary:
  types:
    - http
  schemes_declared: 1
  credential_classes: 2
  api_key_in: []
  oauth2_flows: []
  oidc: false
  mutual_tls: false
  scopes: false
  operations_secured: 55
  operations_unsecured: 4
spec_text: >-
  "All endpoints require an access token generated by the authorization server.
  Include the token in the request headers: Authorization: Bearer
  YOUR_ACCESS_TOKEN. Ensure the token is valid and not expired."
schemes:
  - name: BearerAuth
    type: http
    scheme: bearer
    bearer_format: opaque
    in: header
    header: Authorization
    sources:
      - openapi/quandela-job-token-openapi.yml
      - openapi/quandela-perceval-job-openapi.yml
      - openapi/quandela-perceval-job-token-openapi.yml
      - openapi/quandela-platform-openapi.yml
      - openapi/quandela-qrng-openapi.yml
      - openapi/quandela-quantum-toolbox-openapi.yml
credential_classes:
  note: >-
    THE KEY FINDING. One declared security scheme covers two operationally
    distinct credentials, and the contract does not distinguish them. The tag
    descriptions say which operations want the second one — "Operations about
    job - Authenticate by `Cloud Job Token`" — but tag prose is not machine
    readable as a security requirement, so a generated client or an agent
    reading only securitySchemes cannot tell which credential a given operation
    expects. Both failures return HTTP 401 with different English strings.
  classes:
    - id: account-access-token
      label: Account access token
      issued_by: https://account.quandela.com (referred to in the spec as "the authorization server")
      obtained_via: interactive login at account.quandela.com
      presented_as: 'Authorization: Bearer <token>'
      used_on:
        - 'tag: Api - Job Token (/api/auth/tokens*, /api/tokens/{token_id} administration)'
      failure:
        status: 401
        body: '{"detail":{},"error":"Authentication and authorization failed: token not found"}'
        probe: GET https://api.cloud.quandela.com/api/platforms
        probed: '2026-08-17'
      note: >-
        This is the credential that mints job tokens. Its own issuance is not
        described by any published contract — account.quandela.com serves no
        OIDC or OAuth discovery document (see well-known/quandela-well-known.yml:
        /.well-known/openid-configuration returns an HTML SPA shell, not a
        document), so the token-acquisition step is undocumented and cannot be
        automated from published material.
    - id: cloud-job-token
      label: Cloud Job Token
      issued_by: 'POST /api/tokens (canonical) or POST /api/auth/tokens'
      obtained_via: openapi/quandela-perceval-job-token-openapi.yml#post_api_tokens
      presented_as: 'Authorization: Bearer <token>'
      used_on:
        - 'tag: Api - Perceval Job (job submission, status, result, cancel, rerun)'
        - 'tag: Api - Perceval Job Token'
        - 'tag: QuantumToolbox (/qt/* algorithms)'
        - 'tag: QRNG (/qt/qrng/*)'
      declared_in_tag_description: 'Authenticate by `Cloud Job Token`'
      failure:
        status: 401
        body: '{"detail":{},"error":"Invalid or expired job token"}'
        probe: GET https://api.cloud.quandela.com/api/jobs/availability
        probed: '2026-08-17'
      attributes:
        - {field: label, note: Human-readable name; must be unique per account (400 "Label already exists").}
        - {field: priority, note: 'Queue priority, capped by the user''s own priority (400 "Can''t assign priority higher than user priority").'}
        - {field: duration, note: Requested token lifetime at generation.}
        - {field: expiration_date, note: Computed expiry.}
        - {field: is_explorer_token, note: 'Explorer tier. REJECTED on some operations: 401 "Authentication failed: explorer tokens are not allowed".'}
        - {field: is_apikey, note: Distinguishes a long-lived API key from an interactive token.}
        - {field: valid, note: Current validity.}
        - {field: is_revoked, note: Revocation state (on the list projection).}
      lifecycle:
        create: 'POST /api/tokens'
        list: 'GET /api/tokens (limit/offset, include_expired, include_revoked)'
        read: 'GET /api/tokens/{token_id}'
        update: 'PUT /api/tokens/{token_id} (label, priority)'
        revoke: 'POST /api/tokens/revoke'
        reopen: 'POST /api/tokens/reopen'
        delete: 'POST /api/tokens/delete-by-ids'
        usage: 'GET /api/tokens/usage/report'
      note: >-
        Revocable AND reopenable — an unusual affordance. Rotation is fully
        self-service over the API, which is a genuine strength: an agent can
        mint a short-lived, low-priority, labelled token per workload and revoke
        it afterwards without human involvement.
unsecured_operations:
  count: 4
  note: >-
    The four operations with no security requirement are the service-root and
    specification endpoints, all verified anonymous on 2026-08-17.
  operations:
    - {operation: 'openapi/quandela-platform-openapi.yml#get_root', path: 'GET /', status: 302, note: 'redirects to /api/docs/, which then requires login'}
    - {operation: 'openapi/quandela-platform-openapi.yml#get_health', path: 'GET /health', status: 200, body: '{"message":"ok"}'}
    - {operation: 'openapi/quandela-platform-openapi.yml#get_openapi_json', path: 'GET /openapi.json', status: 200, note: 'the full 59-operation contract, anonymous'}
    - {operation: 'openapi/quandela-platform-openapi.yml#get_qt_openapi_json', path: 'GET /qt-openapi.json', status: 200, note: 'the Quantum Toolbox sub-contract, anonymous'}
  undocumented_anonymous:
    - {url: 'https://api.cloud.quandela.com/api/status', status: 200, body: '{"db":"ok","server":"ok"}'}
    - {url: 'https://api.cloud.quandela.com/api/platforms/public', status: 200, note: 'per-platform status, maintenance windows and daily availability'}
sdk_authentication:
  library: perceval-quandela
  class: perceval.providers.quandela.quandela_session.Session
  signature: Session(platform_name, token, url=None)
  source: https://perceval.quandela.net/docs/v1.2/reference/providers.html
  note: >-
    The Python SDK takes the Cloud Job Token directly as the `token` argument
    and defaults `url` to the Quandela Cloud endpoint. Perceval can persist the
    token in its PersistentData store (path overridable via
    PCVL_PERSISTENT_PATH, added in v1.1.0) so it is not re-supplied per run.
gaps:
  - >-
    Two credential classes share one undifferentiated BearerAuth scheme; which
    credential an operation wants is stated only in tag prose.
  - >-
    No OAuth 2.0 or OIDC. account.quandela.com publishes no discovery document,
    so obtaining the account access token is undocumented and unautomatable from
    public material.
  - No scopes or permissions model — a Cloud Job Token is all-or-nothing within its offer.
  - No token introspection or revocation-check endpoint for a bearer holder.
  - No mTLS, no proof-of-possession, no DPoP.
  - No bearerFormat declared; token structure is opaque and undocumented.
  - The rendered auth documentation is behind a login at account.quandela.com.