generated: '2026-08-26'
method: searched
source: >-
  https://api.scalecomputing.com/api/v2 (Swagger UI description),
  openapi/scale-computing-fleet-manager-openapi.json, openapi/scale-computing-core-openapi.json
docs: https://api.scalecomputing.com/api/v2
summary:
  types:
  - apiKey
  api_key_in:
  - header
  oauth2_flows: []
  note: >-
    The only genuine authentication mechanism Scale Computing publishes for a reachable API is an
    API key sent in an `api-key` request header. There is no OAuth 2.0, no OIDC and no scope model.
schemes:
- name: API Key
  api: SC//Fleet Manager API
  type: apiKey
  in: header
  parameter: api-key
  sources:
  - openapi/scale-computing-fleet-manager-openapi.json
  applied_to: >-
    Every operation in the v2 spec except HealthController_check, via a per-operation
    security requirement.
  issued_at: https://fleet.scalecomputing.com/organization/settings
  created_via_api: 'POST /api/v2/api-keys (ApiKeyController_create)'
  revoked_via_api: 'DELETE /api/v2/api-keys/{id} (ApiKeyController_remove) — irreversible'
  key_metadata: 'ApiKeyDto exposes id, name, organizationId, tokenSuffix, role, createdAt, lastUsed'
  rotation: >-
    No rotation endpoint and no expiry field. Rotation means create-then-revoke, which the caller
    must sequence themselves; there is no overlap or grace window published.
  authorization_model: role
  roles_enumerated: false
  roles_note: >-
    The published description states "Each endpoint is role restricted in alignment with the UI access
    levels, which are detailed in the Fleet Manager User Guide". The role vocabulary is NOT in the
    spec — the only role named anywhere in the contract is "VM Viewer", in the CreateApiKeyDto example
    payload — and the User Guide is a Salesforce-hosted content link, so the authoritative permission
    matrix is not machine-readable and is effectively customer-gated.
  transport_security: 'TLS 1.3; HSTS max-age=31536000; includeSubDomains observed on api.scalecomputing.com'
- name: tsoa_auth
  api: Scale Computing Platform Core API
  type: oauth2
  flows:
  - flow: implicit
    authorizationUrl: http://swagger.io/api/oauth/dialog
    scopes: 0
  sources:
  - openapi/scale-computing-core-openapi.json
  valid: false
  note: >-
    NOT a real Scale Computing authorization server. This is the stock tsoa scaffold placeholder — the
    authorization URL points at swagger.io's demo dialog over plain HTTP and the scope set is empty.
    Recorded so it is not mistaken for OAuth support. The v1 core API's actual credential flow is a
    bearer/session token minted by POST /api/v1/users/me/access-token (CreateAccessToken) and validated
    by GET /api/v1/users/me (AuthenticateUser), but no operation in the spec declares a security
    requirement and no documentation for it is published.
- name: on-appliance auth
  api: SC//HyperCore REST API
  type: http
  scheme: basic
  sources:
  - https://scalecomputing.github.io/HyperCoreAnsibleCollection/
  note: >-
    The HyperCore API is served by the customer's own clustered node, authenticated with cluster user
    credentials (the Ansible collection and Terraform provider take a host, username and password).
    No machine-readable contract for it is published outside the customer network, so this entry is
    recorded from the first-party tooling rather than from a spec.
x-negative-results:
- probe: https://api.scalecomputing.com/.well-known/oauth-authorization-server
  status: 404
- probe: https://api.scalecomputing.com/.well-known/openid-configuration
  status: 404
- probe: https://community.scalecomputing.com/.well-known/openid-configuration
  status: 200
  finding: >-
    Real OIDC discovery document, but it is Salesforce Experience Cloud's issuer for the customer
    community portal (issuer https://community.scalecomputing.com, stock Salesforce scope list). It
    does not authorize either Scale Computing API. See well-known/scale-computing-well-known.yml.