SciToolkit LogoSciToolkit

Authentication

How the SciToolkit CLI signs in. One per-user token authenticates you across every toolkit you have permission on.

The model

A SciToolkit CLI token represents you — your scitoolkit.org account. It does not represent permission for a single toolkit. The backend looks up your role (owner, collaborator, viewer) per toolkit on every action, so one token works for every toolkit you own or collaborate on.

This is the same shape you're used to from gh, npm, cargo: log in once, your permissions follow you.

Sign in (recommended)

Browser-flow login. Opens scitoolkit.org in your default browser, you click Approve, the token is sent back to the CLI automatically.

scitoolkit login
bash

The CLI starts a one-shot localhost server, prints a URL, and opens your browser. Sign in (if you aren't already), confirm the consent screen, and the CLI exits success.

The token is stored at ~/.scitoolkit/token (mode 0600).

Sign in non-interactively (CI, agents)

When a browser isn't available — CI pipelines, headless servers, agent-driven workflows — generate a token in the website and pass it to scitoolkit login --token.

  1. Visit CLI Tokens on scitoolkit.org.
  2. Click Generate token. Optionally name it and set an expiry.
  3. Copy the token — it's shown only once.
  4. Pass it to the CLI:
scitoolkit login --token "sct_user_..."
# Or via env var:
SCITOOLKIT_TOKEN="sct_user_..." scitoolkit login --token "$SCITOOLKIT_TOKEN"
bash

For CI: store the token as a secret and reference it from your pipeline config.

Check who you are

scitoolkit whoami
bash

Prints the email and display name of the authenticated user. Useful sanity check before publishing — "am I signed in as the right account?"

Sign out

scitoolkit logout
bash

Revokes the token at the backend (so it can't be used by anything else) and removes the local credential file.

To clean up legacy per-toolkit tokens at the same time, add --clean-legacy.

Manage tokens

List, name, expire, and revoke tokens at CLI Tokens. Each token shows its name, creation date, last-used date, and expiry. Revoking takes effect immediately — any CLI session using that token is signed out on its next request.

You can have multiple tokens at once — for example, one per laptop, plus a separate one for CI. Naming them at creation makes them easier to identify when you revoke later.

Migrating from per-toolkit tokens

The original SciToolkit MVP used per-toolkit publish tokens — one token per toolkit, generated from each toolkit's management page. Those tokens still work, but they're being phased out:

PhaseStatus
A — concurrentPer-user tokens shipped. Per-toolkit tokens still work and still mintable. Banner appears on toolkit-management pages pointing to per-user.
BPer-toolkit token-creation UI removed. Existing per-toolkit tokens still authenticate. CLI scitoolkit login <toolkit> emits a hard deprecation warning.
CCLI removes the toolkit-arg form of scitoolkit login. Existing per-toolkit tokens accepted indefinitely (for ancient CI scripts) but no new ones minted.

To migrate: run scitoolkit login. If the CLI detects per-toolkit token files, it offers to consolidate to a single per-user token.

Security notes

  • Token format. Per-user CLI tokens are sct_user_<random>. Per-toolkit (legacy) tokens are stk_<random>.
  • Stored hashed on the backend. The raw value is shown to you exactly once at creation; we can't look it up again. If you lose a token, revoke and create a new one.
  • Treat as a password. Don't commit to git, don't paste in chats, don't share. CI: use the platform secrets store.
  • Browser-flow CSRF protection. The CLI generates a random state value, the website round-trips it back, and the CLI validates it before accepting the token. This prevents a malicious website from minting a token for someone else's session.
  • Revocation. Revoking takes effect immediately. No need to wait for an expiry.

Next steps