Authentication
Skylos Cloud currently has three real auth paths:
| Auth path | Best for | Main command |
|---|---|---|
| Browser login | Humans linking a repo to a project | skylos login |
| API key | CI, headless systems, explicit manual control | skylos sync connect <token> or SKYLOS_TOKEN=... |
| GitHub OIDC | Secretless GitHub Actions uploads | skylos . --upload with id-token: write |
Quick Start
skylos . --upload
On the first interactive run, Skylos will:
- open the browser
- let you sign in and choose or create a project
- verify the returned token
- store the repo link
- upload the scan
If you want to connect before running a scan, use:
skylos login
Browser Authentication
skylos login is the preferred human workflow.
skylos login
What it does:
- opens
skylos.dev/cli/connect - signs you in with GitHub if needed
- lets you select or create a project
- verifies the token with
/api/sync/whoami - stores the saved credentials and repo link
Files written:
~/.skylos/credentials.json<repo>/.skylos/link.json
Linking saves the project and credentials for future uploads. A plain
skylos . scan does not upload; add --upload to send its report to Cloud.
skylos .
skylos . --upload
Switching or inspecting the linked project
Useful commands:
skylos project status
skylos project list
skylos project use
skylos project unlink
skylos sync status
Re-running skylos login opens the chooser again. If you complete the flow with a different project, the repo link is updated. If you close the browser flow, the current project is kept.
Manual API Keys
Use API keys when you want explicit, non-browser auth.
Get the key from:
Dashboard -> Settings -> choose project -> API key
The current UI behavior is:
- a newly created key is only shown once
- rotating the key revokes the old one immediately
Save the key to the current repo
skylos sync connect sk_live_xxx...
Or run without an argument and paste it interactively:
skylos sync connect
Use the key for a single run
SKYLOS_TOKEN=sk_live_xxx... skylos . --upload
Best use cases for API keys
- GitLab, CircleCI, Jenkins, and other non-GitHub CI
- headless servers
- scripted uploads
- temporary override of the repo-linked project
GitHub Actions OIDC
OIDC authenticates default-branch uploads without a stored API key. Generate
the full PR gate and upload workflow with skylos cicd init; see
CI/CD Integration.
The generated onboarding workflow described here requires Skylos 4.46.0 or newer. Skylos 4.45.0 has the older workflow generator.
Preconditions:
- your Skylos project is bound to the GitHub repository
- the Skylos GitHub App is installed on that repository
- only the upload job has
id-token: write
This upload-only example assumes one Cloud project for the repository and a
default branch named main. Replace the branch name as needed. For multiple
monorepo projects, use the App's per-root workflow described below.
name: Skylos Cloud upload
on:
push:
branches: [main]
permissions:
contents: read
jobs:
cloud-upload:
if: github.event_name == 'push' && github.ref == format('refs/heads/{0}', github.event.repository.default_branch)
runs-on: ubuntu-latest
timeout-minutes: 15
permissions:
contents: read
id-token: write
steps:
- uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5
with:
fetch-depth: 0
persist-credentials: false
- uses: actions/setup-python@a26af69be951a213d495a4c3e4e4022e16d87065
with:
python-version: '3.12'
- run: python -I -m pip install "skylos>=4.46.0"
- run: skylos sync pull
- run: skylos . --danger --secrets --quality --ai-defects --upload
env:
SKYLOS_COMMIT: ${{ github.sha }}
SKYLOS_BRANCH: ${{ github.ref_name }}
Ordinary pull_request jobs scan code and run tests without OIDC or stored
Cloud credentials. Adding id-token: write to one does not make its upload
trusted. The GitHub App has a separate PR workflow that isolates scanning
from its trusted policy and publishing jobs; use the App's generated workflow
for Cloud-verified PR checks.
How it works:
- GitHub Actions issues a short-lived OIDC token
- Skylos verifies the token against GitHub's OIDC issuer
- Cloud verifies the repository identity and GitHub App binding, then resolves the project, using the project subpath when supplied
- the scan uploads with no
SKYLOS_TOKENsecret
Important repo-binding rule
OIDC requires a unique project for the verified repository and the supplied
project subpath. A monorepo can have projects such as apps/api and
apps/web; Cloud's generated App workflow sends each root separately.
If no project matches, upload fails. If multiple projects still match after subpath routing, or the request omits a subpath and matches several projects, Cloud rejects the ambiguous binding.
The CLI-generated workflow's --scan-path changes the scan directory, but
its skylos sync pull step does not send a GitHub project-subpath header.
Use the App's per-root workflow for Cloud policy sync in a monorepo with
multiple projects.
Token Resolution Order
The current CLI token lookup order is:
SKYLOS_TOKEN- GitHub Actions OIDC
- the current repo link plus
~/.skylos/credentials.json - the legacy default saved token
- system keyring fallback
That means SKYLOS_TOKEN is the cleanest way to override the linked project for one run.
Upload Attribution
Skylos Cloud records upload attribution from the server-side auth path.
| Upload path | Attribution source |
|---|---|
| Browser login | linked user and project credential |
| API key | resolved project key identity |
| GitHub OIDC | verified GitHub OIDC claims and matched project binding |
If two people upload from different machines to the same project, Skylos does not rely only on a client-supplied name. Cloud records the resolved project, auth path, repo/project-root context, branch, commit metadata, and upload time.
For enterprise security review, see Enterprise Trust.
Headless and Remote Environments
If browser auth is unavailable, Skylos falls back to manual token entry.
Use one of these:
skylos sync connect
or:
SKYLOS_TOKEN=sk_live_xxx... skylos . --upload
Troubleshooting
skylos . --upload opens a browser unexpectedly
The CLI could not find a usable token and is trying to connect interactively.
OIDC fails even though id-token: write is set
Check the project's repo URL, the GitHub App installation, and the event.
An ordinary upload job must run on a push to the default branch. Cloud also
accepts its own isolated PR publishing workflow; an arbitrary pull_request
job is not that workflow.
OIDC says the repo is ambiguous
Check that the request identifies the intended project subpath and that only
one project matches that repository and subpath. For monorepos, use the
App-generated per-root workflow; --scan-path alone does not route CLI
policy sync.
A token stopped working
The key may have been rotated or revoked. Generate a new one in dashboard settings and update your CI secrets.
I need to move this repo to a different cloud project
skylos project unlink
skylos login