Auth

vulnd is its own OAuth 2.1 authorization server. There are no API keys and no client_credentials grant — every token is minted for a person who signed in, so every authenticated request is answerable to an account.

Two flows, one server

• Browser — authorization-code + PKCE. The login page sends you to the daemon’s hosted authorize endpoint. You authenticate there (the console never handles your password), and you’re redirected back with a code the server exchanges for tokens. The session is kept server-side; the browser holds only an opaque HttpOnly cookie.
• CLI — device grant (RFC 8628). vuln login asks the daemon for a device code, prints a short user code and a verification URL, and polls while you approve it in a browser. On approval it caches an access token and a refresh token.

Both return the same kind of token; they differ only in how a human approves the grant.

Scopes

Tokens carry scopes. read covers the corpus — though the corpus reads are public anyway, so a token mostly matters for the rate tier and attribution. notes is required to create, list, or delete notes. The console’s browser client requests read; the CLI requests what it needs for the verbs you run.

Refresh

Access tokens are short-lived. Both surfaces hold a refresh token and renew silently before expiry — you sign in once. vuln logout (or signing out in the browser) discards the cached tokens.

Using a token directly

If you’re scripting against the HTTP API, present the access token as a bearer:

curl -s -H "Authorization: Bearer $TOKEN" \
  https://api.vulnd.cypherassassin.com/v1/notes?tag=log4shell

There is no static-token env var and no X-On-Behalf-Of header — the token is the sole proof of identity, validated the same way for the browser, the CLI, and a script.