CB Insights · Authentication Profile

Cb Insights Authentication

Authentication

CB Insights declares 4 security scheme(s) across its OpenAPI definitions.

Companymarket-intelligenceprivate-company-dataventure-capitalfunding-datainvestor-datacompany-datapeople-databusiness-relationshipspredictive-scoringmcpagent-nativedata-enrichmentsnowflake
Methods: Schemes: 4 OAuth flows: API key in:

Security Schemes

BearerAuth apiKey
· in: header (Authorization)
v2 client credentials exchange custom-client-credentials
v1 JWT authorize custom-client-credentials
MCP OAuth 2.1 oauth2

Source

Authentication Profile

Raw ↑
generated: '2026-08-09'
method: searched
source: https://api-docs.cbinsights.com/portal/docs/CBI-API/cbi-authentication
docs:
- https://api-docs.cbinsights.com/portal/docs/CBI-API/cbi-authentication
- https://api-docs.cbinsights.com/portal/docs/quick-start
- https://api-docs.cbinsights.com/docs/tutorials/authentication_flow/
- https://api-docs.cbinsights.com/docs/endpoints/authentication_endpoint/
derived_from:
- openapi/cb-insights-api-v2-openapi.json
- well-known/cb-insights-mcp-oauth-authorization-server.json
- well-known/cb-insights-mcp-oauth-protected-resource.json
summary: >-
  Three distinct authentication models across the CB Insights estate. The REST APIs (v1 and v2) both
  use a CB-Insights-issued clientId/clientSecret pair exchanged at an /authorize endpoint for a
  bearer JWT, which is then sent in the Authorization header of every data call; there is no refresh
  token. The hosted MCP server is separate — it is a full OAuth 2.1 authorization server with
  dynamic client registration and PKCE, which is what lets Claude/ChatGPT/Copilot connect with an
  end-user login rather than an API credential. Credentials are never self-issued: clientId and
  clientSecret come from a CB Insights representative or from the developer-portal trial sign-up.
types:
- apiKey
- oauth2
api_key_in:
- header
schemes:
- name: BearerAuth
  type: apiKey
  in: header
  parameter: Authorization
  format: Bearer <JWT>
  description: >-
    Bearer JWT required on every v2 data operation. Declared in the published Swagger 2.0 contract as
    an apiKey-in-header scheme (Swagger 2.0 has no bearer http type), and additionally declared as a
    required `Authorization` header parameter on each operation.
  applies_to: CB Insights API v2 (all 28 operations except POST /v2/authorize)
  sources:
  - openapi/cb-insights-api-v2-openapi.json
  - https://api-docs.cbinsights.com/portal/docs/CBI-API/cbi-authentication
- name: v2 client credentials exchange
  type: custom-client-credentials
  token_endpoint: https://api.cbinsights.com/v2/authorize
  method: POST
  request_body: '{"clientId": "...", "clientSecret": "..."}'
  response_body: '{"token": "..."}'
  notes: >-
    Documented as a "client credentials flow" but it is NOT RFC 6749 — the request is a bespoke JSON
    body against /v2/authorize rather than an OAuth token endpoint with grant_type. The quick-start
    shows an `expiresIn` field alongside `token`; the authentication reference states the token is
    valid 24 hours and that there is no refresh-token mechanism (re-authorize on expiry).
  sources:
  - https://api-docs.cbinsights.com/portal/docs/CBI-API/cbi-authentication
  - https://api-docs.cbinsights.com/portal/docs/quick-start
- name: v1 JWT authorize
  type: custom-client-credentials
  token_endpoint: https://api.cbinsights.com/v1/authorize
  method: GET
  request: query parameters clientId + clientSecret
  response_body: '{"token": "..."}'
  token_lifetime: 24h
  notes: >-
    The v1 flow passes the client secret as a URL query parameter on a GET request, which puts the
    long-lived secret into proxy, browser and server access logs. v2 moved this to a POST body.
  sources:
  - https://api-docs.cbinsights.com/docs/tutorials/authentication_flow/
  - https://api-docs.cbinsights.com/docs/endpoints/authentication_endpoint/
- name: MCP OAuth 2.1
  type: oauth2
  applies_to: CB Insights MCP Server (https://mcp.cbinsights.com/)
  issuer: https://mcp.cbinsights.com/
  authorization_endpoint: https://mcp.cbinsights.com/authorize
  token_endpoint: https://mcp.cbinsights.com/token
  registration_endpoint: https://mcp.cbinsights.com/register
  grant_types:
  - authorization_code
  - refresh_token
  - client_credentials
  response_types:
  - code
  pkce:
  - S256
  token_endpoint_auth_methods:
  - none
  - client_secret_post
  - client_secret_basic
  scopes_supported:
  - openid
  - email
  - profile
  bearer_methods_supported:
  - header
  discovery:
    oauth_authorization_server: well-known/cb-insights-mcp-oauth-authorization-server.json
    oauth_protected_resource: well-known/cb-insights-mcp-oauth-protected-resource.json
    openid_configuration: well-known/cb-insights-mcp-openid-configuration.json
  notes: >-
    Dynamic client registration is open (registration_endpoint present, token_endpoint_auth_methods
    includes "none"), which is what makes one-click connector setup work in Claude/ChatGPT/Copilot.
    The three scopes advertised are identity scopes only — no data-permission scopes are published,
    so authorization granularity is not expressed in the token.
  sources:
  - https://mcp.cbinsights.com/.well-known/oauth-authorization-server
  - https://mcp.cbinsights.com/.well-known/oauth-protected-resource
credential_issuance:
  self_serve: partial
  detail: >-
    A trial clientId/clientSecret is issued through the developer-portal sign-up form after email
    validation (25 companies, 5 scouting reports, 5 ChatCBI messages). Production credentials are
    issued by a CB Insights representative / CSM — there is no self-serve production key.
  sign_up: https://api-docs.cbinsights.com/portal/signup
enterprise_identity:
  saml_sso:
    supported: true
    initiation: SP-initiated only (IdP-initiated SSO is explicitly not supported)
    idps_documented:
    - Okta (Okta Integration Network app)
    - Azure AD
    docs: https://docs.cbinsights.com/docs/sso/index.html
  scim:
    supported: true
    version_documented: SCIM (version not stated)
    operations:
    - create users
    - update user attributes
    - deactivate users
    primary_identifier: email mapped to SCIM userName
    credential: SCIM API key generated in Account Settings > Single Sign-On
    docs: https://docs.cbinsights.com/docs/scim/index.html
  mfa:
    supported: true
    source: https://www.cbinsights.com/security-and-privacy/
gaps:
- No RFC 6749 / RFC 8414 conformance on the REST token endpoint — the "client credentials flow" is a
  bespoke JSON exchange, so standard OAuth clients cannot be pointed at it.
- No refresh token on the REST APIs; every 24 hours the client must resend the long-lived secret.
- v1 transmits clientSecret in a URL query string.
- No token revocation, introspection, or key-rotation endpoint is documented.
- The MCP authorization server advertises only openid/email/profile — no data scopes, so an agent
  token cannot be narrowed to a subset of the data surface.
cross_links:
  conformance: conformance/cb-insights-conformance.yml
  conventions: conventions/cb-insights-conventions.yml
  well_known: well-known/cb-insights-well-known.yml
  mcp: mcp/cb-insights-mcp.yml