# Eliq authentication profile.
generated: '2026-09-06'
method: searched
source: https://developer.eliq.com/doc/authentication
docs: https://developer.eliq.com/doc/authentication
provider: Eliq
providerId: eliq
summary:
  types:
  - oauth2
  - http
  primary: OAuth 2.0 client credentials issuing a signed JWT bearer token
  note: Derived from the specs this reads as a bare `http bearer` scheme, because the Insights and Intelligence
    documents declare only the bearer half. The provider documents the full OAuth 2.0 client-credentials flow behind
    it, so this file is upgraded to `searched`.
authorization_server:
  issuer: https://auth-api.eliq.com
  token_endpoint: https://auth-api.eliq.com/oauth/token
  jwks_uri: https://auth-api.eliq.com/.well-known/jwks.json
  discovery: https://auth-api.eliq.com/.well-known/openid-configuration
  uat_issuer: https://auth-api-uat.eliq.com
  signing_alg: RS256 (asymmetric)
  grant_types:
  - client_credentials
  - refresh_token
  request_content_types:
  - application/json
  - application/x-www-form-urlencoded
  access_token_lifetime_seconds: 3600
  refresh_token_lifetime_seconds: 2592000
flows:
- name: App token
  grant_type: client_credentials
  use: server-to-server, no end-user context
  fields:
  - grant_type
  - client_id
  - client_secret
  - aud
  - scope (optional)
  note: '`aud` names the target API — data-management-api or insights-api. A token is scoped to one API.'
- name: Delegated token
  grant_type: client_credentials
  use: acting on behalf of one end user; required where the target API enforces user context
  fields:
  - grant_type
  - client_id
  - client_secret
  - aud
  - scope
  - sub
  - sub_type
  - issue_refresh_token (optional)
  note: '`sub` is the user id, `sub_type` typically `user`. This is the delegated-identity mechanism an agent would
    use to act for a named customer.'
- name: Token refresh
  grant_type: refresh_token
  use: exchange a refresh token for a new access token
  fields:
  - grant_type
  - refresh_token
token_claims:
- claim: iss
  description: Token issuer
  example: https://auth-api.eliq.com
- claim: aud
  description: Target API the token is scoped to
  example: data-management-api
- claim: client_id
  description: OAuth application the token belongs to
- claim: org
  description: Organization ID
- claim: org_type
  description: Type of organization
  example: utility
- claim: sub
  description: Identity the token represents (user id, or the client id for an app token)
- claim: sub_type
  description: Type of subject
  example: user | client
- claim: scope
  description: Scopes granted
  example: data.read data.write
- claim: access_type
  description: How access was granted
  example: application | delegated
schemes:
- name: BearerAuth
  type: http
  scheme: bearer
  bearerFormat: JWT
  description: 'Access token issued by the Eliq Auth API, sent as Authorization: Bearer <token>.'
  sources:
  - openapi/eliq-insights-api-openapi.yaml
  - openapi/eliq-intelligence-api-openapi.json
  - https://developer.eliq.com/doc/authentication
credential_management:
  issuance: client_id is issued by an Eliq account manager when the integration is set up.
  secrets: Client secrets are generated via the Client Admin API or by the account manager. Multiple secrets per
    client are supported so secrets can be rotated without downtime.
  portal: Client Admin Portal — shows which APIs the client can reach, the access types and scopes available per
    API, and manages/rotates secrets.
  dynamic_client_registration: false
  note: No DCR, no self-serve key issuance. An agent cannot obtain credentials without a human commercial step.
legacy:
  model: Auth v1 (numeric Utility ClientId)
  status: still supported unchanged; migration offered, not forced
webhook_auth:
  inbound: Eliq signs outbound webhook events with HMAC-SHA256 over "{timestamp}.{json_payload}", carried in the
    X-Eliq-Signature header as t=<unix>,sha256=<hex>. Consumer endpoints must be HTTPS and may additionally require
    Basic auth or OAuth2.
  docs: https://developer.eliq.com/doc/webhooks
requirements:
- TLS (HTTPS) must always be used
- Client secrets and tokens must never be exposed in client-side applications or public repositories
- Compromised tokens must be revoked immediately