generated: '2026-09-14'
method: searched
source: https://developer.authologic.com/docs/technical/implementation,
  openapi/authologic-customer-api-openapi.yml (components.securitySchemes),
  well-known/authologic-sandbox-oauth-authorization-server.json (RFC 8414, probed 2026-09-14),
  live 401 probe of https://sandbox.authologic.com/api/conversations
docs: https://developer.authologic.com/docs/technical/implementation
specification: API Commons Authentication
specificationVersion: '0.1'
provider: Authologic
providerId: authologic
description: >-
  Authologic offers two authentication styles over the same credential pair, and the published OAuth
  authorization server is materially richer than the OpenAPI lets on. The spec declares one
  clientCredentials flow; the RFC 8414 metadata document advertises five grant types, mTLS-bound tokens
  and DPoP.
summary:
  types:
    - http
    - oauth2
  oauth2_flows:
    - clientCredentials
  default_security: 'either scheme satisfies the requirement — security: [{apiKey: []}, {oauth2: []}]'
  applies_to: all 14 operations
  transport: HTTPS only
schemes:
  - name: apiKey
    type: http
    scheme: basic
    label: HTTP Basic
    description: >-
      Username is the account name; password is the environment-specific API key. This is the style every
      published example uses (`curl -u my_login`). The key is generated in the API Keys section of
      OmniPanel and is NOT the OmniPanel account password — the docs call the confusion out explicitly.
    credential_scope: per environment (a sandbox key does not work against production)
    issuance: https://omnipanel.authologic.com
    rotation: >-
      Self-serve — generate a new key in OmniPanel. No rotation policy or key lifetime is published, and
      no expiry is signalled at runtime.
    verified:
      probe: POST https://sandbox.authologic.com/api/conversations
      status: 401
      header: 'www-authenticate: Basic realm="Realm"'
      date: '2026-09-14'
    sources:
      - openapi/authologic-customer-api-openapi.yml
      - https://developer.authologic.com/docs/technical/implementation
  - name: oauth2
    type: oauth2
    label: OAuth 2.0 client credentials
    description: >-
      The same account name and API key are used as client_id and client_secret. POST to the token
      endpoint with Content-Type application/x-www-form-urlencoded and grant_type=client_credentials, then
      send Authorization: Bearer <token> on subsequent calls.
    flows:
      - flow: clientCredentials
        tokenUrl: https://sandbox.authologic.com/api/oauth2/token
        scopes: 0
        scopes_note: >-
          The scopes object is EMPTY in the contract and no scope taxonomy is published anywhere.
          Authorization is account- and environment-scoped, not scope-scoped. See
          scopes/authologic-scopes.yml.
    token_type: Bearer
    token_lifetime: not published
    sources:
      - openapi/authologic-customer-api-openapi.yml
authorization_server:
  metadata_url: https://sandbox.authologic.com/.well-known/oauth-authorization-server
  rfc: RFC 8414
  status: 200
  probed: '2026-09-14'
  file: well-known/authologic-sandbox-oauth-authorization-server.json
  issuer: https://sandbox.authologic.com
  endpoints:
    authorization: https://sandbox.authologic.com/oauth2/authorize
    device_authorization: https://sandbox.authologic.com/oauth2/device_authorization
    token: https://sandbox.authologic.com/api/oauth2/token
    jwks: https://sandbox.authologic.com/api/oauth2/jwks
    introspection: https://sandbox.authologic.com/oauth2/introspect
    revocation: https://sandbox.authologic.com/oauth2/revoke
  grant_types_supported:
    - authorization_code
    - client_credentials
    - refresh_token
    - 'urn:ietf:params:oauth:grant-type:device_code'
    - 'urn:ietf:params:oauth:grant-type:token-exchange'
  response_types_supported:
    - code
  token_endpoint_auth_methods_supported:
    - client_secret_basic
    - client_secret_post
    - client_secret_jwt
    - private_key_jwt
    - tls_client_auth
    - self_signed_tls_client_auth
  code_challenge_methods_supported:
    - S256
  tls_client_certificate_bound_access_tokens: true
  dpop_signing_alg_values_supported:
    - RS256
    - RS384
    - RS512
    - PS256
    - PS384
    - PS512
    - ES256
    - ES384
    - ES512
  finding: >-
    A significant undocumented capability gap. The developer documentation describes Basic auth only and
    the OpenAPI declares only clientCredentials, yet the environment advertises authorization_code with
    PKCE, refresh tokens, the device grant, token exchange, private_key_jwt, mutual-TLS client
    authentication with certificate-bound access tokens (RFC 8705) and DPoP (RFC 9449). For an agent
    integrator that is the difference between a shared static secret and a cryptographically bound
    workload credential — and nothing in the docs mentions it is available.
webhook_authentication:
  direction: inbound (Authologic to integrator)
  scheme: HMAC-SHA-256
  headers:
    - X-Signature
    - X-Signature-Timestamp
  key: >-
    A dedicated signature key issued by Authologic, distinct from the API key. Replaced at go-live along
    with the API address and API key.
  replay_window_minutes: 5
  detail: asyncapi/authologic-callbacks-webhooks.yml
gaps:
  - No OpenID Connect discovery document (/.well-known/openid-configuration returns 404 on every host).
  - No /.well-known/oauth-protected-resource (RFC 9728), so an MCP-style client cannot discover the
    authorization server from the resource.
  - No published token lifetime, no key-rotation policy and no runtime expiry signal for API keys.
  - >-
    Production (api.authologic.com) adds an IP allowlist on top of credentials — an unlisted caller never
    reaches the auth layer and receives an nginx 403 HTML page instead of a JSON error.
maintainers:
  - FN: Kin Lane
    email: kin@apievangelist.com