Coresignal Authentication

generated: '2026-08-13'
method: searched
source: >-
  https://docs.coresignal.com/api-introduction/authorization,
  https://docs.coresignal.com/self-service/account-management/authentication-and-api-keys,
  https://docs.coresignal.com/integrations/coresignal-mcp,
  well-known/coresignal-oauth-authorization-server.json,
  well-known/coresignal-oauth-protected-resource.json,
  openapi/_original/*.yml
docs: https://docs.coresignal.com/api-introduction/authorization
note: >-
  Upgraded from a derived spec-only profile. Coresignal runs TWO distinct authentication models on the
  same estate and they should not be conflated: the REST data APIs take a bare 32-character API key in
  an `apikey` header with no scopes and no expiry, while the MCP v2 agent surface takes a full OAuth
  2.1 authorization-code flow against the dashboard and resolves the team's API key server-side.
summary:
  types: [apiKey, oauth2, openIdConnect]
  api_key_in: [header]
  oauth2_flows: [authorizationCode, clientCredentials, refreshToken]
  oauth2_scope: MCP v2 only
  mutual_tls: false
  signed_requests: false
schemes:
  - name: apiKey
    type: apiKey
    in: header
    parameter: apikey
    applies_to: All REST endpoints on https://api.coresignal.com/cdapi/v2/
    format: 32-character alphanumeric string
    issued_at: https://dashboard.coresignal.com/ (API keys section)
    also_issued_by: account manager or sales representative on request for an API plan
    multiple_keys: true
    rotatable: true
    revocable: true
    expiry: none documented
    scopes: none
    note: >-
      Entitlement is the plan attached to the account, not the key. Keys can be generated, regenerated
      and deleted from the dashboard; issuing a key per environment or per downstream tenant is the
      only isolation mechanism available, since there is no least-privilege model.
    example_header: 'apikey: <API_Key>'
    sources:
      - openapi/_original/coresignal-multi-source-company-api-openapi.yml
      - openapi/_original/coresignal-multi-source-employee-api-openapi.yml
      - openapi/_original/coresignal-multi-source-jobs-api-openapi.yml
      - https://docs.coresignal.com/api-introduction/authorization
  - name: Coresignal Dashboard OAuth 2.1
    type: oauth2
    applies_to: https://mcp.coresignal.com/mcp/v2 (MCP server)
    issuer: https://dashboard.coresignal.com/api/auth
    flows:
      - flow: authorizationCode
        authorizationUrl: https://dashboard.coresignal.com/api/auth/oauth2/authorize
        tokenUrl: https://dashboard.coresignal.com/api/auth/oauth2/token
        pkce_required: S256
        scopes: [openid, profile, email, offline_access]
      - flow: clientCredentials
        tokenUrl: https://dashboard.coresignal.com/api/auth/oauth2/token
      - flow: refreshToken
        tokenUrl: https://dashboard.coresignal.com/api/auth/oauth2/token
    dynamic_client_registration: https://dashboard.coresignal.com/api/auth/oauth2/register
    introspection: https://dashboard.coresignal.com/api/auth/oauth2/introspect
    revocation: https://dashboard.coresignal.com/api/auth/oauth2/revoke
    protected_resource_metadata: https://mcp.coresignal.com/.well-known/oauth-protected-resource/mcp/v2
    resource_scopes_supported: []
    bearer_methods_supported: [header]
    token_endpoint_auth_methods: [none, client_secret_basic, client_secret_post]
    note: >-
      The MCP server verifies the signed token on each request and retrieves the team's API key
      server-side, so no key is stored on the server or in client config. Because the protected
      resource advertises an EMPTY scope list, a valid token grants every tool including the
      credit-spending ones.
    sources:
      - well-known/coresignal-oauth-authorization-server.json
      - well-known/coresignal-oauth-protected-resource.json
      - https://docs.coresignal.com/integrations/coresignal-mcp
  - name: Coresignal Dashboard OpenID Connect
    type: openIdConnect
    applies_to: Dashboard sign-in (identity layer under the OAuth 2.1 flow above)
    openIdConnectUrl: https://dashboard.coresignal.com/.well-known/openid-configuration
    jwks_uri: https://dashboard.coresignal.com/api/auth/jwks
    userinfo_endpoint: https://dashboard.coresignal.com/api/auth/oauth2/userinfo
    end_session_endpoint: https://dashboard.coresignal.com/api/auth/oauth2/end-session
    id_token_signing_alg: [RS256]
    subject_types: [public]
    claims: [sub, iss, aud, exp, iat, sid, scope, azp, email, email_verified, name, picture, family_name, given_name]
    prompt_values: [login, consent, create, select_account, none]
    acr_values: ['urn:mace:incommon:iap:bronze']
    sources: [well-known/coresignal-openid-configuration.json]
legacy_mcp:
  endpoint: https://mcp.coresignal.com/mcp
  scheme: apiKey
  header: apikey
  note: >-
    The legacy MCP endpoint takes the same REST API key as a header (commonly passed through the
    `mcp-remote` bridge). Its tools/list is anonymously introspectable. Coresignal states it will
    eventually be deprecated in favour of the OAuth-protected v2 endpoint.
failures:
  - status: 401
    meaning: No valid API Key was provided (REST), or no/invalid bearer token (MCP v2).
    body_rest: '{"detail": "..."}'
    body_mcp: '{"error": "invalid_token", "error_description": "Authentication required"}'
    challenge_mcp: >-
      WWW-Authenticate: Bearer error="invalid_token",
      resource_metadata="https://mcp.coresignal.com/.well-known/oauth-protected-resource/mcp/v2"
transport:
  https_required: true
  note: >-
    All requests must be made over HTTPS; HTTP requests fail or are redirected. See
    security/coresignal-domain-security.yml for TLS/HSTS posture.
gaps:
  - No scopes or least-privilege model on either surface.
  - No documented key expiry or forced rotation.
  - No mTLS, no request signing, no IP allowlisting documented.