Sybilion Authentication

generated: '2026-08-11'
method: searched
source: https://sybilion.dev/docs/authentication
derived_from: openapi/sybilion-operational-api-openapi.yml
docs: https://sybilion.dev/docs/authentication
note: >-
  The OpenAPI declares exactly one scheme (http bearer, no bearerFormat) applied to all ten
  /api/v1/* operations, with /health left unsecured. The docs are richer than the spec: they
  distinguish THREE credential kinds behind that one header, and they describe a second, entirely
  separate OAuth surface on the MCP server that the OpenAPI does not mention at all.
summary:
  types: [http, oauth2]
  http_schemes: [bearer]
  api_key_in: [header]
  oauth2_flows: [authorizationCode]
  surfaces: 2
  unauthenticated_operations: ['GET /health']
schemes:
  - name: bearerAuth
    type: http
    scheme: bearer
    bearerFormat: null
    surface: rest
    applies_to: https://api.sybilion.dev
    sources: [openapi/sybilion-operational-api-openapi.yml]
    header: 'Authorization: Bearer <token>'
    accepted_credentials:
      - kind: api_key
        prefix: sk_ops_
        issuance: Developers Portal -> API keys
        shown_once: true
        retrievable_later: false
        revocable: true
        rotation_policy: not published
        expiry: not published
        env_var: SYBILION_API_TOKEN
        note: >-
          Opaque key, no scopes, no per-key permissions. One key grants the full account surface
          including billing history and balance.
      - kind: session_token
        issuer: Auth0
        issuer_host: auth0.sybilion.com
        format: JWT access token from the Developers Portal session
        audience: sybilion
        note: accepted on the same Authorization header as the API key
    failure: 401 with {"error":"missing bearer token","trace_id":"..."}
  - name: mcp-oauth
    type: oauth2
    surface: mcp
    applies_to: https://mcp.sybilion.dev/mcp
    sources:
      - https://mcp.sybilion.dev/.well-known/oauth-authorization-server
      - https://mcp.sybilion.dev/.well-known/oauth-protected-resource
      - https://sybilion.dev/docs/integrations
    discovered_by: probe
    flows:
      - flow: authorizationCode
        authorizationUrl: https://mcp.sybilion.dev/oauth/authorize
        tokenUrl: https://mcp.sybilion.dev/oauth/token
        scopes: [openid, profile, email, offline_access]
    pkce: [S256, plain]
    dynamic_client_registration: https://mcp.sybilion.dev/oauth/register
    revocation: https://mcp.sybilion.dev/oauth/revoke
    jwks_uri: https://sybilion.eu.auth0.com/.well-known/jwks.json
    bearer_methods: [header]
    challenge: 'WWW-Authenticate: Bearer resource_metadata="https://mcp.sybilion.dev/.well-known/oauth-protected-resource/mcp"'
    note: >-
      No API key is used here. The docs are explicit that an MCP client runs the browser approval
      flow and that there is nothing to paste into the connector config. The server implements both
      RFC 8414 and RFC 9728 discovery plus RFC 7591 dynamic client registration, which is a
      materially better OAuth posture than the REST side's opaque static key.
  - name: portal-oidc
    type: openIdConnect
    surface: portal
    applies_to: https://sybilion.dev
    openIdConnectUrl: https://auth0.sybilion.com/.well-known/openid-configuration
    sources: [well-known/sybilion-openid-configuration.json]
    discovered_by: probe
    note: >-
      Auth0 custom domain backing the Developers Portal login. Not an API credential surface in its
      own right, but it is the issuer of the session tokens the REST API accepts.
gaps:
  - The OpenAPI gives bearerAuth no bearerFormat and no description, so a generated client cannot tell an sk_ops_ key from a JWT.
  - No scopes, roles or per-key permissions exist on the REST surface; the key is all-or-nothing.
  - Key rotation, expiry and maximum key count are not documented.
  - The MCP OAuth surface is absent from the OpenAPI entirely and is only discoverable by probing /.well-known/.