Ciloo · Authentication Profile

Ciloo Authentication

Authentication

Ciloo secures its APIs with http across 2 declared security schemes, as derived from its OpenAPI definitions.

CompanyPrintingBranded MerchandisePromotional ProductsPrint On DemandeCommerceDigital Asset ManagementProcurementFulfillmentMarketing
Methods: http Schemes: 2 OAuth flows: API key in:

Security Schemes

oauth1a http
scheme: OAuth · in: Authorization header ()
basicAuth http
scheme: basic

Source

Authentication Profile

Raw ↑
generated: '2026-08-12'
method: searched
source: openapi/ciloo-cart-api-openapi.yml
docs: https://api.cilooprint.com/ciloo-cart-api-documentation/#authentication-setup
summary:
  types:
  - http
  http_schemes:
  - OAuth
  - basic
  oauth_version: 1.0a
  oauth2_flows: []
  api_key_in: []
  note: >-
    Ciloo authenticates with OAuth 1.0a (HMAC-SHA1), not OAuth 2.0. There is no authorization server, no
    scope surface, no OIDC discovery document and no bearer-token endpoint. One endpoint —
    generateCustomerLoginToken — uses HTTP Basic instead.
schemes:
- name: oauth1a
  type: http
  scheme: OAuth
  spec: RFC 5849
  signature_method: HMAC-SHA1
  in: Authorization header
  description: >-
    OAuth 1.0a with HMAC-SHA1. Required parameters: oauth_consumer_key, oauth_signature_method,
    oauth_timestamp, oauth_nonce, oauth_version, oauth_signature. Content-Type must be
    application/x-www-form-urlencoded on the ciloo/v1 namespace — a JSON content type causes signature
    failures. Body parameters are merged into the signature base string for POST and PUT only; path
    parameters (such as asset_id) are included. Signing key is urlencode(consumer_secret) + "&" — there
    is no token secret, so this is the two-legged variant.
  sources:
  - openapi/ciloo-cart-api-openapi.yml
  applies_to:
  - getCartItems
  - addCartItem
  - updateCartItem
  - removeCartItem
  - generateCustomerKeys
  - generateLoginToken
  - createCustomer
  - updateCustomer
- name: basicAuth
  type: http
  scheme: basic
  description: >-
    HTTP Basic authentication using the consumer key as username and consumer secret as password. The
    provider flags this as a deliberate exception to the OAuth rule.
  sources:
  - openapi/ciloo-cart-api-openapi.yml
  applies_to:
  - generateCustomerLoginToken
credential_tiers:
- name: admin
  prefixes: [ck_admin_, cs_admin_]
  issued_by: Ciloo
  purpose: Generating per-customer OAuth keys. The provider states these should not be used for cart operations.
- name: customer
  prefixes: [ck_, cs_]
  issued_by: POST /wp-json/ciloo/v1/generate_customer_keys
  purpose: All cart operations, scoped to a single customer account.
  delivery: >-
    Keys are POSTed to a callback_url supplied on the request; return_keys=1 additionally returns them
    in the response body.
session_tokens:
  mechanism: auto-login token
  issued_by: [generateLoginToken, generateCustomerLoginToken]
  ttl_seconds: 3600
  bound_to: customer + ip_address
  transport: query string — {base_url}?action=autologin&token=<token>&path=/cart
weaknesses_documented_by_provider:
- >-
  oauth_timestamp and oauth_nonce are accepted without validation, so OAuth 1.0a replay protection is
  not enforced by the implementation.
- >-
  Session tokens travel in a URL query string, which is exposed to browser history, referrers and
  intermediate logs.
- Newly minted customer credentials are delivered over an integrator-supplied callback URL.
missing:
- No OAuth 2.0 or OpenID Connect surface (no scopes artifact is emitted — there are no scopes).
- No mTLS, no signed requests on the printer callbacks, no key-rotation API.