Connected Kerb · Authentication Profile

Connected Kerb Authentication

Authentication

Connected Kerb secures its APIs with http and oauth2 across 3 declared security schemes, as derived from its OpenAPI definitions. OAuth 2.0 is offered via the clientCredentials flow(s).

CompanyEV ChargingElectric VehiclesCharge Point OperatorEnergyTransportationSmart ChargingOCPIRoamingUnited KingdomInfrastructureSustainability
Methods: http, oauth2 Schemes: 3 OAuth flows: clientCredentials API key in:

Security Schemes

ocpiToken http
scheme: token
bearerAuth http
scheme: bearer
oauth2ClientCredentials oauth2
· flows: clientCredentials

Source

Authentication Profile

connected-kerb-authentication.yml Raw ↑
generated: '2026-08-04'
method: searched
source: live probes of https://cp.connectedkerb.com + platform authorization
  documentation at https://developers.ampeco.com/reference/authorization-1
docs: https://developers.ampeco.com/reference/authorization-1
note: |
  Connected Kerb publishes no first-party developer portal, no authentication guide
  and no OpenAPI, so there is nothing in this repo to derive a spec-based auth
  profile from. This profile was assembled instead from (a) live unauthenticated
  probes of the two API surfaces Connected Kerb actually operates on its own hosts
  and (b) the published contract of the platform those surfaces run on. Every
  status code below was observed, not assumed.
summary:
  types: [http, oauth2]
  api_key_in: []
  http_schemes: [bearer, token]
  oauth2_flows: [clientCredentials]
  oauth2_enabled_on_this_tenant: false
  self_service_credentials: false
  credential_issuance: manual - commercial agreement or operator back office
schemes:
- name: ocpiToken
  surface: connected-kerb:ocpi
  type: http
  scheme: token
  description: >-
    OCPI Token-based authentication per the Open Charge Point Interface
    specification. Credentials are exchanged bilaterally through the OCPI
    credentials module rather than issued self-service; the endpoint rejects
    anonymous callers with an OCPI status envelope rather than a plain HTTP body.
  endpoints:
    versions: https://cp.connectedkerb.com/ocpi/versions
    credentials: https://cp.connectedkerb.com/ocpi/2.2.1/credentials
  evidence:
  - url: https://cp.connectedkerb.com/ocpi/versions
    http_status: 401
    content_type: application/json
    body: '{"status_code":2001,"status_message":"Unauthorized","timestamp":"2026-08-04T16:00:15Z"}'
    response_headers: [OCPI-from-party-id, OCPI-from-country-code, OCPI-to-party-id,
      OCPI-to-country-code, X-Request-ID, X-Correlation-ID]
  - url: https://cp.connectedkerb.com/ocpi/2.2.1/credentials
    http_status: 401
- name: bearerAuth
  surface: connected-kerb:public-api
  type: http
  scheme: bearer
  bearerFormat: API Token
  description: >-
    Long-lived UUID API token passed as `Authorization: Bearer <token>`. Tokens are
    created in the operator back office (API Access Tokens), scoped by an
    assigned role, and optionally restricted to whitelisted source IPs or to a
    single partner. There is no public sign-up path for API credentials.
  evidence:
  - url: https://cp.connectedkerb.com/public-api/resources/charge-points/v1.0
    http_status: 401
    content_type: application/json
    body: '{"message":"Unauthenticated."}'
    response_headers: ['X-App-Version: 3.225.1 (9e5dd506)', x-req-trace-id]
- name: oauth2ClientCredentials
  surface: connected-kerb:public-api
  type: oauth2
  status: not-enabled-on-this-tenant
  description: >-
    The platform contract documents an OAuth 2.0 client-credentials grant (RFC 6749
    section 4.4) exchanging a hex client_secret at /public-api/oauth/token for a
    short-lived bearer access token, with an empty scopes map. It is NOT enabled on
    Connected Kerb's tenant - the token endpoint answers "Feature is not enabled" -
    so in practice the only working credential on this deployment is a long-lived
    bearer API token. That is the weaker of the two options the platform offers.
  flows:
  - flow: clientCredentials
    tokenUrl: https://cp.connectedkerb.com/public-api/oauth/token
    scopes: {}
  evidence:
  - url: https://cp.connectedkerb.com/public-api/oauth/token
    method: POST
    http_status: 404
    body: '{"message":"Feature is not enabled"}'
  - url: https://cp.connectedkerb.com/public-api/oauth/token
    method: GET
    http_status: 405
other_gated_surfaces:
- name: Customer portal
  url: https://portal.connectedkerb.com/
  auth: Microsoft Entra ID / MSAL browser sign-in (no anonymous API)
  evidence:
  - url: https://portal.connectedkerb.com/api/tenant/config
    http_status: 401
    body: '{"error":"Unauthorized"}'
- name: Umbraco Delivery API (marketing site CMS)
  url: https://www.connectedkerb.com/umbraco/delivery/api/v2/content
  auth: API key required; not a published developer surface
  evidence:
  - url: https://www.connectedkerb.com/umbraco/delivery/api/v2/content
    http_status: 401
    content_type: application/problem+json
gaps:
- No Connected Kerb authentication documentation exists on any Connected Kerb host.
- No self-service credential issuance for either API surface.
- OAuth 2.0 client credentials is available in the platform but switched off on this
  tenant, leaving long-lived bearer tokens as the only mechanism.
- No scopes are defined for the OAuth flow even where it is enabled, so there is no
  least-privilege scope surface to document (scopes/ is intentionally not emitted).