Bluecore Authentication

generated: '2026-07-18'
method: searched
source: https://developers.bluecore.com/reference/authn
docs: https://developers.bluecore.com/reference/authn
summary:
  model: oauth2-client-credentials
  types:
  - oauth2
  - http-bearer
  api_key_in:
  - header
  oauth2_flows:
  - clientCredentials
  notes: >-
    Bluecore uses the standard OAuth 2.0 client-credentials grant. Clients POST client_id +
    client_secret to https://auth.bluecore.com/oauth/token (audience https://a.bluecore.com,
    grant_type client_credentials) and receive a Bearer access_token valid for 24 hours (86,400s).
    Requests to the API then send `authorization: Bearer <token>`. In the published per-operation
    OpenAPI the bearer scheme is modelled as an apiKey security scheme named "GlooAuth"
    (in: header, name: authorization) rather than an oauth2 scheme, so the mechanical oauth2
    scope derivation does not fire; the real flow and scopes are captured here and in scopes/.
schemes:
- name: GlooAuth
  type: http
  scheme: bearer
  in: header
  parameter: authorization
  description: >-
    Bearer access token obtained from the client-credentials token endpoint. Value is
    "Bearer " followed by the token returned by POST https://auth.bluecore.com/oauth/token.
  sources:
  - openapi/bluecore-openapi.yml
  - https://developers.bluecore.com/reference/authn_getaccesstoken
- name: TransactionalStaticKey
  type: http
  scheme: bearer
  in: header
  parameter: Authorization
  applies_to: https://api.bluecore.com/email/
  description: >-
    The LEGACY transactional API is protected by a long-lived, customer-specific API key issued by
    Bluecore, sent as `Authorization: Bearer {Bluecore API Key}`. There is no token endpoint, no
    expiry, no scopes and no rotation flow documented; the published contract says to email
    support@bluecore.com to obtain or cycle a key, and warns the key must never be used from a
    browser. This is a materially weaker auth model than the OAuth surface and is on a different
    host — an integrator on the legacy API gains nothing from the OAuth documentation.
  sources:
  - openapi/bluecore-transactional-legacy-api-openapi.yml
  - https://www.bluecore.com/transactional-api-docs/
- name: EventsTenantToken
  type: apiKey
  in: body
  parameter: properties.token
  applies_to: https://api.bluecore.app/api/track/mobile/v1
  description: >-
    The Events API authenticates with the tenant `token` (the Bluecore namespace) carried inside
    the JSON request body rather than in a header. No Authorization header, no expiry, no scopes.
    Because the same token is embedded in the client-side website tag, it is a public write
    credential by design.
  sources:
  - https://help.bluecore.com/help/events-api
token_endpoint:
  url: https://auth.bluecore.com/oauth/token
  grant_type: client_credentials
  audience: https://a.bluecore.com
  token_type: Bearer
  expires_in: 86400
  credentials_docs: https://help.bluecore.com/help/create-an-api-key
authorization_server:
  generated: '2026-08-13'
  method: probed
  issuer: https://auth.bluecore.com/
  platform: Auth0
  discovery:
  - {path: /.well-known/oauth-authorization-server, status: 200, spec: RFC 8414,
     file: well-known/bluecore-oauth-authorization-server.json}
  - {path: /.well-known/openid-configuration, status: 200, spec: 'OpenID Connect Discovery 1.0',
     file: well-known/bluecore-openid-configuration.json}
  - {path: /.well-known/jwks.json, status: 200, spec: RFC 7517, file: well-known/bluecore-jwks.json}
  endpoints:
    authorization: https://auth.bluecore.com/authorize
    token: https://auth.bluecore.com/oauth/token
    device_authorization: https://auth.bluecore.com/oauth/device/code
    userinfo: https://auth.bluecore.com/userinfo
    revocation: https://auth.bluecore.com/oauth/revoke
    registration: https://auth.bluecore.com/oidc/register
    jwks: https://auth.bluecore.com/.well-known/jwks.json
  token_endpoint_auth_methods_supported: [client_secret_basic, client_secret_post, private_key_jwt, none]
  code_challenge_methods_supported: [S256, plain]
  signing_algs: [RS256, RS384, PS256]
  detail: >-
    Discovered 2026-08-13 — round 1 recorded "no /.well-known/ documents on any Bluecore host"
    because auth.bluecore.com had not been probed. The metadata describes the authorization server
    that actually issues Bluecore API access tokens, so a client can now discover the token
    endpoint and verify token signatures without reading the docs. Note the advertised scope set
    (openid, profile, email, phone, address, offline_access) is the generic Auth0 OIDC set and is
    NOT the Bluecore API scope vocabulary — the real API scopes are the `resource:verb` strings in
    scopes/bluecore-scopes.yml.
multi_surface_warning: >-
  Bluecore operates three API surfaces with three different and incompatible auth models:
  OAuth 2.0 client-credentials (a.bluecore.com/api), a static Bearer API key
  (api.bluecore.com/email/, legacy), and a tenant token inside the request body
  (api.bluecore.app/api/track/mobile/v1). See conventions/bluecore-conventions.yml
  surface_divergence.