Actively · Authentication Profile

Actively Authentication

Authentication

Actively AI protects its hosted MCP server (https://api.actively.ai/mcp) with OAuth 2.1 authorization-code + PKCE against a first-party authorization server at https://auth.actively.ai, which also speaks full OpenID Connect. There is no API-key surface: the only published, machine-discoverable authentication path is OAuth. No public REST API is published, so no securityScheme block exists to derive from — the profile below is read from live discovery metadata.

Actively declares 3 security scheme(s) across its OpenAPI definitions.

CompanyAi AppsAI AgentsRevenue IntelligenceSalesGo To MarketMCPOAuthModel Context ProtocolSales IntelligenceEnterprise Software
Methods: Schemes: 3 OAuth flows: API key in:

Security Schemes

oauth2
openIdConnect
oauth2

Source

Authentication Profile

actively-authentication.yml Raw ↑
generated: '2026-08-13'
method: probed
source: >-
  https://api.actively.ai/.well-known/oauth-protected-resource +
  https://auth.actively.ai/.well-known/openid-configuration +
  https://auth.actively.ai/.well-known/oauth-authorization-server
docs: null
docs_note: >-
  Actively publishes no developer documentation host and no written auth guide.
  This profile is derived entirely from the machine-readable discovery
  documents the provider serves anonymously, not from prose.
description: >-
  Actively AI protects its hosted MCP server (https://api.actively.ai/mcp) with
  OAuth 2.1 authorization-code + PKCE against a first-party authorization
  server at https://auth.actively.ai, which also speaks full OpenID Connect.
  There is no API-key surface: the only published, machine-discoverable
  authentication path is OAuth. No public REST API is published, so no
  securityScheme block exists to derive from — the profile below is read from
  live discovery metadata.

schemes:
- id: oauth2_authorization_code
  type: oauth2
  applies_to: https://api.actively.ai/mcp
  flow: authorization_code
  pkce_required_methods:
  - S256
  authorization_endpoint: https://auth.actively.ai/oauth2/authorize
  token_endpoint: https://auth.actively.ai/oauth2/token
  jwks_uri: https://auth.actively.ai/oauth2/jwks
  registration_endpoint: https://auth.actively.ai/oauth2/register
  introspection_endpoint: https://auth.actively.ai/oauth2/introspection
  grant_types:
  - authorization_code
  - refresh_token
  - urn:ietf:params:oauth:grant-type:device_code
  token_endpoint_auth_methods:
  - none
  - client_secret_post
  - client_secret_basic
  response_types:
  - code
  response_modes:
  - query
  bearer_methods_supported:
  - header
  note: >-
    The api-host mirror of the metadata narrows this for MCP clients
    specifically: grant_types [authorization_code, refresh_token],
    token_endpoint_auth_methods ["none"] — i.e. public clients with PKCE and
    no client secret.

- id: oidc
  type: openIdConnect
  applies_to: https://auth.actively.ai
  openid_configuration: https://auth.actively.ai/.well-known/openid-configuration
  issuer: https://auth.actively.ai
  userinfo_endpoint: https://auth.actively.ai/oauth2/userinfo
  id_token_signing_alg_values_supported:
  - RS256
  subject_types_supported:
  - public
  grant_types:
  - authorization_code
  - client_credentials
  - refresh_token
  - urn:ietf:params:oauth:grant-type:device_code
  note: >-
    client_credentials appears in the OIDC document but NOT in the
    MCP-facing authorization-server mirror, so machine-to-machine tokens are
    not advertised for the MCP resource.

- id: device_code
  type: oauth2
  flow: urn:ietf:params:oauth:grant-type:device_code
  device_authorization_endpoint: https://auth.actively.ai/oauth2/device_authorization
  note: >-
    Device authorization grant is supported, which is the flow a headless
    agent or CLI would use. Not documented anywhere in prose.

dynamic_client_registration:
  supported: true
  endpoint: https://auth.actively.ai/oauth2/register
  spec: RFC 7591
  client_id_metadata_document_supported: true
  note: >-
    An MCP client can register itself with no prior contact with Actively.
    This is what makes the endpoint reachable from a cold start.

token:
  placement: header
  scheme: Bearer
  challenge: >-
    Bearer error="invalid_token",
    resource_metadata="https://api.actively.ai/.well-known/oauth-protected-resource/mcp"
  challenge_note: >-
    The 401 carries a spec-compliant RFC 9728 WWW-Authenticate challenge that
    points the client at its own discovery document — the behaviour an MCP
    client needs to bootstrap.

identity_provider:
  vendor: WorkOS AuthKit
  evidence: >-
    app.actively.ai 307-redirects unauthenticated requests to
    https://api.workos.com/user_management/authorize?client_id=client_01K26EZTNS1CRN2ABZ0Z37Y2MW&provider=authkit,
    and auth.actively.ai is the branded custom domain for the same tenant.
  note: >-
    Recorded as an infrastructure fact, not a criticism — the authorization
    server is served from Actively's own domain and issues Actively's tokens.

not_published:
- api_keys: No API-key or personal-access-token surface is documented anywhere.
- mtls: No mutual-TLS scheme advertised.
- basic_auth: Not offered on the API surface.
- auth_documentation: >-
    No human-readable authentication guide, quickstart, or developer portal
    exists. Everything here had to be probed.

evidence:
- fetched: '2026-08-13'
  url: https://api.actively.ai/.well-known/oauth-protected-resource
  http_status: 200
- fetched: '2026-08-13'
  url: https://api.actively.ai/.well-known/oauth-authorization-server
  http_status: 200
- fetched: '2026-08-13'
  url: https://auth.actively.ai/.well-known/openid-configuration
  http_status: 200
- fetched: '2026-08-13'
  url: https://auth.actively.ai/.well-known/oauth-authorization-server
  http_status: 200
- fetched: '2026-08-13'
  url: https://api.actively.ai/mcp
  http_status: 401
  note: WWW-Authenticate challenge observed.