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 "" 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.