Swift Navigation Authentication

generated: '2026-08-29'
method: searched
source: >-
  https://support.swiftnav.com/support/solutions/articles/44002519397-ntrip-client-configuration-for-skylark-corrections
  ; https://support.swiftnav.com/support/solutions/articles/44002287337-skylark-portal-user-guide
  ; https://skylark-prod.us.auth0.com/.well-known/openid-configuration (probed 200)
  ; grpc/swift-navigation-sora-device-v1beta-service.proto
name: Swift Navigation authentication profile
note: >-
  Swift Navigation publishes no OpenAPI, so this profile is assembled from the surfaces that DO
  document their own auth: the NTRIP client-configuration article, the Skylark Portal user guide,
  the Skylark Auth0 tenant's OIDC discovery document, and a comment block inside the Sora protobuf
  contract. There are three distinct schemes and they do not share credentials.
schemes:
  - id: skylark_ntrip_basic
    api: Skylark Precise Positioning Service
    type: http
    scheme: basic
    in: header
    header: Authorization
    description: >-
      Skylark correction streams are authenticated with an NTRIP username and password issued
      per DEVICE, not per account. The username is "<device-suffix>" derived from the account
      username chosen at sign-up (lowercase letters, digits and hyphens; must start with a letter
      and end with a letter or digit).
    credential_issuance:
      where: Skylark User Portal, Devices tab, ADD NEW DEVICE
      url: https://account.swiftnav.com/
      requires: account plus either a valid payment method or a promo code (or an unexpired 14-day trial)
    credential_recovery:
      recoverable: false
      detail: >-
        Documented explicitly by the provider, and it is the single most important operational fact
        on this surface: "For security reasons, passwords are not stored in a recoverable form and
        are no longer visible after the window is closed." A lost NTRIP password can only be
        replaced by generating a new one, which rotates the credential on the device.
    revocation:
      detail: >-
        Credentials are disabled automatically when a subscription lapses — at the end of an
        unconverted free trial, shortly after a failed scheduled payment, or at the end of a
        billing cycle with auto-renew off. Re-enabling a payment method reactivates them.
    transport_security:
      - {port: 2101, tls: false, note: Basic credentials travel in the clear on the standard NTRIP port.}
      - {port: 2102, tls: true}
      - {port: 2103, tls: mutual, note: mTLS; requires NTRIP v2.}
  - id: skylark_portal_oidc
    api: Skylark User Portal / account and subscription services
    type: openIdConnect
    openid_connect_url: https://skylark-prod.us.auth0.com/.well-known/openid-configuration
    description: >-
      The Skylark User Portal and its two backend services
      (account-service.skylark.swiftnav.com, subscription-service.skylark.swiftnav.com) authenticate
      against an Auth0 tenant, skylark-prod.us.auth0.com, with audience https://account.swiftnav.com.
      The tenant was identified from the portal's own public runtime configuration at
      https://account.swiftnav.com/runtime-config.js.
    issuer: https://skylark-prod.us.auth0.com/
    endpoints:
      authorization: https://skylark-prod.us.auth0.com/authorize
      token: https://skylark-prod.us.auth0.com/oauth/token
      device_authorization: https://skylark-prod.us.auth0.com/oauth/device/code
      jwks: https://skylark-prod.us.auth0.com/.well-known/jwks.json
      revocation: https://skylark-prod.us.auth0.com/oauth/revoke
      registration: https://skylark-prod.us.auth0.com/oidc/register
    scopes_supported: [openid, profile, offline_access, name, given_name, family_name, nickname, email, email_verified, picture, created_at, identities, phone, address]
    scopes_note: >-
      These are the stock OIDC/Auth0 identity scopes. NO Skylark-specific API scopes
      (read:devices, write:subscriptions, or similar) are advertised in the discovery document and
      none are documented publicly, so an integrator cannot see what a Skylark token is allowed to do
      before requesting one.
    grant_types_supported: [client_credentials, authorization_code, refresh_token, password, implicit, 'urn:ietf:params:oauth:grant-type:device_code', 'urn:ietf:params:oauth:grant-type:token-exchange', 'urn:ietf:params:oauth:grant-type:jwt-bearer']
    code_challenge_methods_supported: [S256, plain]
    token_endpoint_auth_methods_supported: [client_secret_basic, client_secret_post, private_key_jwt, none]
    id_token_signing_alg_values_supported: [HS256, RS256, PS256]
  - id: sora_device_flow
    api: Sora API (gRPC)
    type: oauth2
    flow: device_code
    rfc: RFC 8628
    description: >-
      A Sora device client calls the unauthenticated DeviceService.AuthServerInfo RPC, which returns
      Auth0AuthServerInfo {host, client_id, audience}, then runs an OAuth 2.0 Device Authorization
      Grant against that Auth0 host. The browser leg of the flow is where a human associates the
      device with a Sora project.
    source: grpc/swift-navigation-sora-device-v1beta-service.proto (comment on AuthServerInfo)
    status: >-
      Contract-documented but not exercisable — grpc.sora.swiftnav.com presents a placeholder
      Kubernetes ingress certificate, so the AuthServerInfo bootstrap cannot complete.
  - id: web_data_anonymous
    api: Swift Navigation web data endpoints
    type: none
    description: >-
      The first-party JSON endpoints under https://www.swiftnav.com/wp-json/ that power the Skylark
      portal and the compatibility checker (receiver catalog, country availability, support FAQ,
      footer) are served with NO authentication and no key. Verified by anonymous probe, HTTP 200.
gaps:
  - >-
    No API-key mechanism, no machine-to-machine credential and no documented service account for the
    Skylark account or subscription services. Everything an integrator can automate today is either
    the anonymous sourcetable/web-data reads or an NTRIP stream keyed to a single device.
  - >-
    No published scope reference. The Auth0 discovery document advertises only identity scopes, and
    Swift Navigation documents no authorization model for its backend services.