RunBuggy · Authentication Profile

Runbuggy Authentication

Authentication

RunBuggy runs three distinct authentication models across its estate, and only the first is described in a specification: an opaque bearer token for the REST Shippers API, a short-lived scope=openid JWT for the embeddable order-status iframe, and full OAuth 2.1 with dynamic client registration and PKCE for the mcp-datascience MCP server.

RunBuggy secures its APIs with apiKey and oauth2 across 3 declared security schemes, as derived from its OpenAPI definitions.

CompanyAutomotiveLogisticsTransportationVehicle ShippingMarketplaceSupply ChainFleetTMSFreight
Methods: apiKey, oauth2 Schemes: 3 OAuth flows: API key in: header

Security Schemes

Authorization apiKey
· in: header (Authorization)
order-status-jwt oauth2
mcp-oauth oauth2

Source

Authentication Profile

Raw ↑
generated: '2026-08-05'
method: searched
source: https://docs.runbuggy.com/docs/shipping/b6b6c2d4906e9-authentication, openapi/runbuggy-orders.json,
  openapi/runbuggy-authentication.json, well-known/runbuggy-oauth-authorization-server.json
docs: https://docs.runbuggy.com/docs/shipping/b6b6c2d4906e9-authentication
description: 'RunBuggy runs three distinct authentication models across its estate, and
  only the first is described in a specification: an opaque bearer token for the REST
  Shippers API, a short-lived scope=openid JWT for the embeddable order-status iframe,
  and full OAuth 2.1 with dynamic client registration and PKCE for the mcp-datascience
  MCP server.'
summary:
  types:
  - apiKey
  - oauth2
  api_key_in:
  - header
schemes:
- name: Authorization
  surface: REST Shippers API (Orders, Companies)
  type: apiKey
  in: header
  parameter: Authorization
  format: Bearer {token}
  description: See the [Authentication Guide](/docs/shipping/b6b6c2d4906e9-authentication).
  sources:
  - openapi/runbuggy-companies.json
  - openapi/runbuggy-orders.json
  acquisition:
    self_service: false
    documented_path: Contact your RunBuggy representative to retrieve a Bearer token.
    programmatic: POST /login on the Authentication API (base https://ng-staging.runbuggy.com/staging/api/auth)
      returns a login-response carrying the token.
    operationId: login
  applied_to: all 28 published operations, uniformly
  rotation: not documented
  expiry: not documented
  note: Declared as `apiKey` rather than Swagger 2.0's http/bearer style, so generated
    clients treat the whole "Bearer {token}" string as the key value. Callers must
    include the literal "Bearer " prefix themselves.
- name: order-status-jwt
  surface: embeddable order-status iframe
  type: oauth2
  flow: token exchange — an authenticated API bearer token is POSTed to the platform
    oauth2/token endpoint with body {"scope":"openid"} to mint a JWT
  token_type: JWT
  documented_expiry_seconds: 60
  passed_in: URL query parameter `token` on the iframe src
  source: https://docs.runbuggy.com/docs/shipping/d483faef38c3b-embedding-i-frame-order-status
  note: Not present in any published specification — the endpoint is documented only in
    prose. The documented pattern moves a bearer credential through a URL query string.
- name: mcp-oauth
  surface: RunBuggy Data Science MCP server
  type: oauth2
  spec: OAuth 2.1 authorization code with PKCE (S256) and RFC 7591 dynamic client
    registration
  issuer: https://apps.runbuggy.com/runbuggy/mcp-datascience
  authorization_endpoint: https://apps.runbuggy.com/runbuggy/mcp-datascience/authorize
  token_endpoint: https://apps.runbuggy.com/runbuggy/mcp-datascience/token
  registration_endpoint: https://apps.runbuggy.com/runbuggy/mcp-datascience/register
  revocation_endpoint: https://apps.runbuggy.com/runbuggy/mcp-datascience/revoke
  grant_types_supported: [authorization_code, refresh_token]
  token_endpoint_auth_methods_supported: [client_secret_post, client_secret_basic]
  scopes_supported: null
  metadata_file: well-known/runbuggy-oauth-authorization-server.json
  note: The most modern auth in the estate, and the one RunBuggy documents least — it
    appears nowhere on runbuggy.com or docs.runbuggy.com.
mfa:
  end_user: RunBuggy's security page describes replacing passwords with immutable
    credentials backed by device-TPM private keys (a phishing-resistant model) for
    platform users. This applies to the application, not to API tokens.
  source: https://runbuggy.com/security/
gaps:
- No self-service credential issuance for the REST API — every integration begins with a
  human at RunBuggy.
- No documented token lifetime, rotation or revocation for the REST bearer token.
- No scopes on the REST API; a token is all-or-nothing across order creation,
  cancellation and webhook management.
- The iframe token exchange endpoint is undocumented in any specification.
- The MCP OAuth server publishes no scopes_supported and its protected-resource metadata
  is unreachable.
x-evidence:
  fetched: '2026-08-05'
  probes:
  - url: https://docs.runbuggy.com/docs/shipping/b6b6c2d4906e9-authentication
    http_status: 200
  - url: https://apps.runbuggy.com/.well-known/oauth-authorization-server
    http_status: 200
  - url: https://apps.runbuggy.com/runbuggy/mcp-datascience/mcp
    http_status: 401