User & auth management
Dousen has two planes, each with its own users and roles. Knowing which plane you are working in tells you how to add people, what role they get, and how they sign in.
The two planes
| Plane | What it manages | Roles |
|---|---|---|
| Cloud control plane | Studios/orgs and billing. | owner, admin, member |
| Studio instance | What artists actually sign into day to day. | admin, producer, artist |
Access checks on the studio instance are effectively admin vs non-admin. When a cloud user signs into their studio, an owner or admin becomes an instance Admin; everyone else becomes an Artist.
How people sign in
A studio instance supports three sign-in modes:
- Self-hosted — the password is checked against the instance itself.
- External directory — LDAP/AD/OIDC. Authentication is delegated to your directory, and the user is auto-provisioned on first login.
- Cloud — there is no instance password. Users arrive through a secure single-sign-on exchange from the control plane.
Browser sign-in
From the desktop app, sign-in can open the browser and use a secure OAuth flow (PKCE). A user who belongs to more than one studio gets a "choose a studio" picker before landing in their instance.
Sessions & tokens
Sessions are handled automatically — there is little for an admin to manage day to day:
- Short-lived access tokens refresh in the background.
- Refresh tokens last 30 days and rotate each time they are used.
- Single-device enforcement: signing in elsewhere ends other sessions. A refresh or heartbeat from a different device is rejected, and the app shows "session active on another device."
Creating users
This is the part that differs most between the two planes.
Cloud studio (control plane)
You invite people; they set their own password.
- An
owneroradminsends an email invite —POST /api/orgs/:id/invites. - The invitee clicks the link and sets their own password —
POST /api/invites/accept. - Review who hasn't accepted yet with
GET /api/orgs/:id/invites.
On a cloud studio the admin never sets a member's password — the invite flow puts that in the invitee's hands.
Self-hosted studio instance
There is no invite flow. An admin creates the user directly in the portal.
| Action | Endpoint |
|---|---|
| Create a user | POST /portal/users |
| Change a user's role | PUT /portal/users/:id/role |
Creating a user takes an email, display name, password, and role. The admin sets the initial password, or uses "send reset" to email the user a reset link instead.
Seats & plans
Each plan includes a default seat count:
| Plan | Default seats |
|---|---|
| Trial | 5 |
| Starter | 25 |
| Pro | 100 |
| Enterprise | 500 |
Seat limits are enforced when creating or inviting users and again at sign-in — going over the limit is refused. The studio instance sends a daily license heartbeat to the control plane:
- A single day of overage just warns.
- If usage stays over the limit for three days, the studio is suspended and the owner is emailed.
- It auto-reactivates as soon as usage drops back under the limit.
Admin guards
In the studio portal, management pages require an admin role — non-admins are redirected to their own account page. Every user, regardless of role, can always manage their own account, profile, password, and active sessions.
Admin does / System does automatically
| Topic | Admin does | System does automatically |
|---|---|---|
| org/tenant setup | Create the org and choose a plan. | Provisions the studio instance and applies the seat count. |
| cloud members | Send invites; assign owner/admin/member. | Lets invitees set their own password; maps owner/admin to instance Admin, others to Artist. |
| instance users | Create users in the portal; set initial password or send reset; set role. | Auto-provisions directory users on first login. |
| seats | Stay within plan limits; upgrade when needed. | Enforces limits, warns on overage, suspends after three days, auto-reactivates. |
| sessions | Nothing routine. | Refreshes tokens, rotates refresh tokens, enforces single-device sign-in. |