Multica / Reference
Authentication and tokens
Multica has three tokens - one for the browser, CLI, and daemon. Which one to use in any scenario.

Overview
Multica has three tokens, corresponding to three usage scenarios: browser Web UI, command line/script, and daemon. All three represent the same you, but have different scopes and validity periods.
Three kinds of tokens
In daily use, you will only come into direct contact with the first two. The daemon token is automatically generated and refreshed by multica daemon login, you don't need to worry about it.
| Token | Format | Where to use | Validity period |
|---|---|---|---|
| JWT Cookie | multica_auth cookie (HttpOnly) |
Web browser | 30 days |
| Personal Access Token (PAT) | Starts with mul_ |
CLI / Script / Call API directly | Does not expire by default; expires_in_days can be passed when creating with API |
| Daemon Token | Starts with mdt_ |
Daemon communicates internally with the server | Managed by the daemon itself |
Which APIs can be accessed by the three tokens?
PAT hits almost anything - it stands for "whole you." What the Daemon Token can do is very limited, it is only enough for the daemon to pull tasks and report results.
| API Routing | JWT Cookie | PAT | Daemon Token |
|---|---|---|---|
/api/user/* (user-level operations) |
✓ | ✓ | ✗ |
/api/workspaces/:id/* (workspace level) |
✓ | ✓ | ✗ |
/api/daemon/* (daemon only) |
✗ | ✓ | ✓ |
WebSocket /ws (real-time push) |
✓ (cookie) | ✓ (first message authentication) | ✗ |
It is also accessing /api/daemon/*, but the scope of the two is different: PAT represents an entire user-you can see all your workspaces after coming in; the daemon token is tied to a workspace when it is created, and can only move the resources of this workspace. Use daemon token to run daemon for production deployment. Do not use PAT for convenience - permissions will be amplified.
Login
Email + verification code
- Fill in your email address and the server will send an email with a 6-digit verification code.
- Enter the verification code, and the server will issue a JWT cookie (browser) or exchange PAT (CLI)
Note on self-deployment operation and maintenance: Keep
MULTICA_DEV_VERIFICATION_CODEempty when deploying on the public network. If fixed local test verification codes are enabled, whenAPP_ENVis not in production, anyone who can request a verification code can log in with this fixed value. See Self-deployed authentication configuration for details.
Google OAuth
Click Sign in with Google and use the standard OAuth callback. GOOGLE_CLIENT_ID / GOOGLE_CLIENT_SECRET / redirect URI needs to be configured during self-deployment - see Self-deployment authentication configuration for details.
Create, view, revoke PAT
There are two ways to create:
- Web UI: Settings → Personal Access Tokens → New token
- CLI:
multica loginwill automatically create one if there is no PAT locally
**The complete content of PAT is only displayed once when it is created. ** It will no longer be visible after refreshing the page or closing the dialog box. Multica only saves the hash value of PAT in the database - the server cannot retrieve it. Copy and save immediately when created. If you lose it, you can only undo it and recreate it.
View the issued PAT list (name, creation time, last use time, excluding complete token): Settings → Personal Access Tokens.
Revoke PAT: Click Revoke in the list. Revocation is effective immediately - the next request for a revoked PAT will be a 401.
Logging out just deletes the local token.
When executing multica auth logout or exiting at the Web UI point:
- Local token cleared - CLI deletes PAT from
~/.multica/config.json; Web deletes cookies - Server-side PAT is still valid - If someone has already obtained your PAT before logging out (such as copying it to another machine), they can continue to use it
**If you suspect a PAT leak, don't just logout. ** Go to Settings → Personal Access Tokens and deactivate that PAT. Revoking will make the leaked token invalid immediately.
Next step
- CLI Command Quick Check - Authentication of each CLI command is automatic
- Self-deployed authentication configuration - How to configure email/OAuth/signup whitelist during self-deployment
- Daemon Processes and Runtimes - Where does the daemon process token come from?