Nexad · Authentication Profile

Nexad Authentication

Authentication

Nexad secures its APIs with apiKey and oauth2 across 2 declared security schemes, as derived from its OpenAPI definitions. OAuth 2.0 is offered via the deviceCode flow(s).

CompanyArtificial IntelligenceAdvertisingMarketingMarketing AutomationContextual AdvertisingMobile SDKAgent
Methods: apiKey, oauth2 Schemes: 2 OAuth flows: deviceCode API key in: sdk-config

Security Schemes

nexad-android-sdk apiKey
· in: sdk-config ()
soku-nexstudio-api oauth2

Source

Authentication Profile

nexad-authentication.yml Raw ↑
generated: '2026-08-13'
method: searched
source:
  - https://docs.nex.ad/docs/android/getting-started
  - https://soku.ai/cli/skill.md
  - https://raw.githubusercontent.com/About-Intelligence/soku-cli/main/skills/soku/references/auth-workspace.md
  - https://raw.githubusercontent.com/About-Intelligence/soku-cli/main/skills/soku/references/egress-security.md
  - https://raw.githubusercontent.com/About-Intelligence/soku-cli/main/SECURITY.md
  - https://api.soku.ai/api/cli/capabilities
notes: >-
  Nexad has no published OpenAPI, so this profile is searched from provider docs
  and live probes rather than derived from securitySchemes. Two distinct products
  with two distinct auth models. Upgraded 2026-08-13 with the token-storage,
  rotation and third-party credential model published in the company's own repo,
  and with the observed 401 challenge shapes.
summary:
  types: [apiKey, oauth2]
  api_key_in: [sdk-config]
  oauth2_flows: [deviceCode]
  scopes_published: false
  authorization_model: human-review-gate
schemes:
  - name: nexad-android-sdk
    product: Nexad Android Ads SDK
    type: apiKey
    credentials:
      - App ID
      - Publisher ID
    in: sdk-config
    provisioning: >-
      Credentials are issued after submitting the Nexad contact form; the team
      returns a unique App ID and Publisher ID passed to NexadSDK.initialize().
      There is no self-serve key issuance for the SDK.
    source: https://docs.nex.ad/docs/android/getting-started
  - name: soku-nexstudio-api
    product: Soku (NexStudio) API
    type: oauth2
    flow: deviceCode
    standard: OAuth 2.0 Device Authorization Grant (RFC 8628)
    endpoint: https://api.soku.ai
    token_type: Bearer
    detail: >-
      The Soku CLI authenticates via an OAuth device-login flow (`soku auth
      login`), returning a verification_uri and a user_code and resumable with
      `--device-code <device_code>`. Direct calls to api.soku.ai/v1,
      api.soku.ai/api/cli and api.soku.ai/mcp return HTTP 401 without a token.
      Third-party provider credentials are injected SERVER-SIDE via `soku egress`
      rather than handled by the user.
    source: https://soku.ai/cli/skill.md
    token_storage:
      primary: OS keychain via keytar (optional dependency)
      fallback: file-backed store at ~/.soku/credentials.json, mode 0600
      bypass: SOKU_NO_KEYCHAIN=1 (recommended for shell/container agents to avoid an indefinite keychain/D-Bus wait)
      env_injection: SOKU_TOKEN (the provider's preferred path for CI and headless agents)
    rotation:
      procedure: soku auth logout then soku auth login
      guidance: Published in SECURITY.md — rotate immediately if a token may have been exposed.
    scopes:
      published: false
      statement: >-
        Quoted from the provider's own reference doc: "A default `soku auth login`
        reaches the entire CLI surface — there is no resource model to grant or
        check." A token is therefore all-or-nothing across 281 actions. No
        scopes/ artifact is emitted for this provider because there is no scope
        surface to capture.
    authorization:
      mechanism: human review gate
      detail: >-
        Least-privilege is enforced at EXECUTION time rather than at token-issue
        time. 124 of 281 published actions carry requires_review=true and create a
        pending review that a human must approve before the write executes. This is
        an unusual and, for an agent-facing API, a defensible substitute for
        scopes — but it does mean a leaked token grants full read access to every
        connected ad and analytics account immediately.
      see: agentic-access/nexad-agentic-access.yml
    observed_challenges:
      checked: '2026-08-13'
      probes:
        - {url: 'https://api.soku.ai/v1', status: 401, body: '{"success":false,"data":null,"error":{"code":"unauthorized","message":"Invalid or expired token","details":null},"meta":null}'}
        - {url: 'https://api.soku.ai/api/cli/capabilities', status: 401, body: '{"error":"missing_bearer","message":"missing_bearer"}'}
        - {url: 'https://api.soku.ai/mcp', status: 401, note: 'tools/list JSON-RPC POST; no WWW-Authenticate header returned'}
third_party_credentials:
  model: server-side injection
  detail: >-
    For covered third-party APIs the caller never holds the key. `soku egress --
    curl ...` strips empty placeholder auth and Soku injects the real credential
    server-side. `soku egress providers` lists covered hosts. The provider
    explicitly instructs agents NOT to preflight or guard on a local key env var.
  source: https://raw.githubusercontent.com/About-Intelligence/soku-cli/main/skills/soku/references/egress-security.md
discovery_gaps:
  - {document: /.well-known/openid-configuration, status: 404-or-401, impact: No OIDC discovery.}
  - {document: /.well-known/oauth-authorization-server, status: 404-or-401, impact: 'No RFC 8414 metadata; device/token endpoints are undiscoverable outside the CLI.'}
  - {document: /.well-known/oauth-protected-resource, status: 401, impact: 'No RFC 9728 metadata, so an MCP client cannot discover how to authorize against /mcp.'}