Vibe Coding
Back to Multica

Multica / Reference

Authentication and tokens

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

Authentication and tokens key concepts infographic
Authentication and tokens key concepts infographic

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

  1. Fill in your email address and the server will send an email with a 6-digit verification code.
  2. 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_CODE empty when deploying on the public network. If fixed local test verification codes are enabled, when APP_ENV is 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 login will 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