Rubicon Project · Authentication Profile

Rubicon Project Authentication

Authentication

Rubicon Project secures its APIs with apiKey and http across 2 declared security schemes, as derived from its OpenAPI definitions.

CompanyAdvertisingAdTechProgrammatic AdvertisingSell-Side PlatformSSPReal-Time BiddingConnected TVAd ServingMediaOpenRTBReporting
Methods: apiKey, http Schemes: 2 OAuth flows: API key in: header

Security Schemes

api_key apiKey
· in: header (Authorization)
bearer_token http
scheme: bearer

Source

Authentication Profile

Raw ↑
generated: '2026-08-12'
method: searched
source: https://springserve.atlassian.net/wiki/spaces/SSD/pages/1573617663/API+-+Getting+Started
docs:
- https://springserve.atlassian.net/wiki/spaces/SSD/pages/1573617663/API+-+Getting+Started
- https://springserve.atlassian.net/wiki/spaces/CLD/pages/3649929246/CL+-API+-+Getting+Started
- https://console.springserve.com/api-docs
derived_from:
- openapi/rubicon-project-springserve-v1-openapi.yml
- openapi/rubicon-project-springserve-v0-openapi.yml
summary:
  types:
  - apiKey
  - http
  api_key_in:
  - header
  oauth2: false
  openid_connect: false
  mutual_tls: false
  credential_issuance: self-service-within-account
schemes:
- name: api_key
  type: apiKey
  in: header
  parameter: Authorization
  description: >-
    SpringServe authorization token based authentication. The opaque token returned by
    POST /api/v1/auth (or /api/v0/auth) is sent bare in the Authorization header, with no
    scheme prefix — `Authorization: <token>`.
  sources:
  - openapi/rubicon-project-springserve-v0-openapi.yml
  - openapi/rubicon-project-springserve-v1-openapi.yml
- name: bearer_token
  type: http
  scheme: bearer
  bearerFormat: JWT
  description: >-
    SpringServe bearer token authentication. The same POST /api/v1/auth response also
    carries a bearer_token, sent as `Authorization: Bearer <token>`.
  sources:
  - openapi/rubicon-project-springserve-v0-openapi.yml
  - openapi/rubicon-project-springserve-v1-openapi.yml
token_endpoint:
  method: POST
  paths:
  - /api/v1/auth
  - /api/v0/auth
  operation_ids:
  - auth_post
  request_body:
    email: API user email
    password: API user password
  response_fields:
  - token
  - bearer_token
  note: >-
    Credentials are a console user's own email and password — there is no separate client
    ID / client secret. The docs recommend creating a dedicated API user with a plus-address
    (name+api@example.com) via Settings -> Users so API-originated changes are attributable
    in the changelog.
token_lifetime:
  value: 2
  unit: hours
  source: https://springserve.atlassian.net/wiki/spaces/SSD/pages/1573617663/API+-+Getting+Started
  note: 'Published verbatim: "A token expires after two hours."'
session:
  cookie_auth: true
  note: >-
    The hosted Swagger UI at /api-docs authenticates with the console session cookie by
    default; token and bearer auth take precedence when supplied. Cookie/session auth is a
    property of the docs host, not a documented integration path.
  inspect_operations:
  - session_get
  - session_delete
account_context:
  header: x-auth-context
  description: >-
    Every authenticated request runs in the context of the caller's currently active
    account. Read it with GET /api/v1/accounts/current, change it with
    POST /api/v1/accounts/{id}/set_current, or override it per-request with the
    x-auth-context header. Multi-account integrations must set this explicitly.
  operations:
  - accounts_current_get
  - accounts_id_set_current_post
impersonation:
  supported: true
  operations:
  - run_as_start_post
  - run_as_stop_post
  note: >-
    A privileged "run as" surface exists (POST /api/v1/run_as/start, /stop) and returns 403
    "You are not authorized to access this page." when the caller lacks the grant.
gaps:
- No OAuth 2.0, OIDC or mTLS surface is published; there is no scoped third-party
  authorization flow, so an integration holds full user-equivalent rights.
- Password-grant style authentication means an integration stores a human user's console
  password, and the docs offer no key rotation or revocation endpoint.
- The 2-hour token lifetime is documented but no refresh endpoint is published; clients
  must re-POST /auth.