Secret Double Octopus Authentication

generated: '2026-08-26'
method: searched
source: >-
  https://support.doubleoctopus.com/support/solutions/articles/33000275542-how-to-configure-the-help-desk-role,
  https://support.doubleoctopus.com/support/solutions/articles/33000294232-frequently-ask-questions,
  https://docs.pingidentity.com/auth-node-ref/latest/cloud/secret-double-octopus.html
docs: https://support.doubleoctopus.com/support/solutions/articles/33000275542-how-to-configure-the-help-desk-role
api: Octopus Management Console REST API
note: >-
  DERIVATION IMPOSSIBLE: SDO publishes no OpenAPI, so no securityScheme could be read. Everything
  below is read from SDO's public support articles and from identity-vendor integration docs that
  describe configuring against a real Octopus server. It is a description of the documented auth
  model, not a transcription of a spec.
security_schemes:
- id: octopus_api_token
  type: apiKey
  in: header
  documented_as: API Token
  description: >-
    A REST API service is created in the Octopus Management Console; the resulting API Token is read
    from the Sign On tab of that service ("click View, then Copy"). Integrations are configured with
    three values together — the API token, the service URL, and the service certificate.
  issued_by: Octopus Management Console (admin creates a REST API service)
  rotation: not-published
  header_name: not-published
  evidence:
  - https://docs.pingidentity.com/auth-node-ref/latest/cloud/secret-double-octopus.html
  - https://github.com/ForgeRock/Secret-Double-Octopus-Auth-Tree-Node
- id: service_certificate
  type: mutualTLS
  documented_as: service certificate
  description: >-
    Integrations are given a service certificate alongside the API token and service URL, so the
    channel to the Octopus server is certificate-pinned/mTLS in addition to the token.
  evidence:
  - https://docs.pingidentity.com/auth-node-ref/latest/cloud/secret-double-octopus.html
oauth2: false
openid_connect:
  supported: true
  role: >-
    SDO acts as an identity/authentication provider TO applications over OIDC, SAML, WS-Federation,
    WS-Trust and RADIUS. That is the product's application-integration surface, not the auth model
    of the Management Console REST API, which uses the API token above.
  discovery_document: not-published
  note: >-
    No /.well-known/openid-configuration is served on any SDO-controlled host — the OIDC issuer is
    each customer's own deployed Octopus server, not a vendor host.
authorization:
  model: role-based, resource+method ACL
  description: >-
    Console roles are scoped with JSON rules of the form
    {"resource": "<REST API URL>", "methods": ["<Method1>", "<Method2>"], "action": "<allow/deny>"},
    where the resource string is only the portion of the URL following <URL>:<port>/api/. The
    permissible resource/method pairs are enumerated on the deployment's own REST API reference at
    <URL>:<port>/docs/.
  evidence: https://support.doubleoctopus.com/support/solutions/articles/33000275542-how-to-configure-the-help-desk-role
  scopes_artifact: not-applicable
end_user_authenticators:
- mobile push (Octopus Authenticator, iOS and Android)
- biometrics / facial
- FIDO2 security keys
- X.509 smart cards
- Windows Hello
- OTP tokens
- Bluetooth Low Energy offline authentication