User and auth management

Updated October 2026

Describes how to invite and manage users on a studio instance, how roles and sign-in methods work, and how cloud organization membership relates to them.

Invite an artist and verify access

These steps work on a self-hosted instance and on a cloud studio. For how each type of studio handles the invite, see Invites on a self-hosted instance and Invites on a cloud studio.

1. Sign in to the web portal as an Admin, open Users, and click Invite User.
2. Enter the email, display name, and role, then click Send invite. You don’t set a password.
3. Read the message above the list. With local passwords or on a cloud studio, the new row shows a Pending invite badge until the person sets a password or accepts the cloud invitation.
4. Ask the artist to accept the invite and sign in to DousenDesktop against the studio URL. On a self-hosted instance with local passwords, they set a password of at least 8 characters from the emailed link.
5. Have them select the intended project. Check that their normal artist workflow works and that admin-only configuration isn’t available to them.

If the invite is refused, check the available seats and your own role. For a directory or cloud account, fix the directory account or the organization membership instead of setting a local password. To create the first admin on a new self-hosted instance, see Self-hosted install.

After you change a role, ask the person to sign in and check that they have the access you expect.

Cloud roles and studio roles

Cloud roles and studio roles are stored in separate databases and checked independently. A DousenControl role only sets a person’s starting role on an instance, the first time they sign in through the cloud. See Which role wins.

Roles on a studio instance

The organization creator remains an active Admin. Their row is marked Organization creator and Admin (protected), with no role-change or deactivation control. The first local account created on a fresh self-hosted instance is also a protected Admin. Other users can change roles, provided at least one active Admin remains; pending invites and deactivated users do not satisfy that requirement.

The whole web portal (/portal/*) requires the web_portal license feature, and every console page requires the Admin role. The console covers projects, conventions, validators, pipeline settings, users, changelists, assets, the health dashboard, the validation history page, and the material-catalog viewer.

The JSON REST API doesn’t redirect. Each admin-only endpoint checks the role itself and returns 403 to anyone else.

Invite and manage users

Admins manage a studio instance’s users on the portal’s Users page. Screenshots on this page use sample accounts.

Invites on a self-hosted instance

• Local passwords: Invite User creates the account with no password and emails the invitee a link to set one. The link is valid for 7 days. The email goes out over the instance’s own SMTP server (see Self-hosted install).
• Directory sign-in (LDAP): Invite User creates the account with the role you chose and sends no email. The person signs in with their directory credentials, and that first sign-in attaches to the account, provided that Dousen has a user search base (see Self-hosted install). The banner reads "<email> can now sign in with their directory credentials".

Invites on a cloud studio

On a cloud studio, Invite User creates the row with the role you chose and asks DousenControl to send a team invitation. DousenControl owns the invitation email, the seat check, and the acceptance step. No password is set in the portal, and the portal’s sign-in page redirects to cloud sign-in.

• The invitee becomes a member of the organization in DousenControl, whatever role you choose. Their first cloud sign-in attaches to the pending row, which keeps the role you chose on the studio instance.
• The invitation expires after 7 days and holds a seat until then. The row then shows an Invite expired badge and stops counting against seats, but it still attaches with its chosen role if the person signs in later.
• Remove cancels the emailed invitation first, so the link stops working, and then deletes the row. If the person has already joined the organization, Dousen refuses and tells you to remove them from the team in DousenControl.
• Resend invite appears only on an expired invite. It asks DousenControl for a new invitation and counts the row against seats again.

Invite messages

After you click Send invite, the Users page shows one of these messages:

If a user with that email already exists, the invite is refused with "A user with <email> already exists". Change their role in the list instead, or use Resend invite if they haven’t set up their account yet. With directory sign-in, inviting an existing email updates that account’s role and display name instead.

HTTPPOST /portal/users HTTP/1.1
Content-Type: application/x-www-form-urlencoded

csrf_token=…&email=jane%40studio.com&display_name=Jane+Doe&role=artist

Deactivate and reactivate a user

When someone leaves the studio, click Deactivate in their row. The user can’t sign in by any method, and their sessions end on their next request. Their changelists and history stay. A deactivated row shows a red Deactivated badge and a Reactivate button.

• You can’t deactivate your own account, the last active admin, or a pending invite. Use Remove for an invite.
• On a self-hosted instance, deactivating a user frees their seat, and Reactivate takes one again. If no seat is free, it fails with the seat-limit message. On a cloud studio, deactivating doesn’t free a seat. To free it, remove the member from the Dousen organization in the cloud dashboard.
• Inviting the email address of a deactivated user fails and tells you to use Reactivate.

Seats

Inviting a user checks the seat limit before it creates the row, and pending invites count. On a self-hosted instance, the limit is the seat count in your license, and an invite holds a seat from the moment you send it. If no seats are left, the invite fails with "Seat limit reached (n/n). Upgrade your plan to add more users." On a cloud studio, DousenControl checks the organization’s limit, and a refused invite shows "seat limit reached — upgrade your plan to invite more members". To free a seat on a self-hosted instance, Deactivate a user or Remove a pending invite. See Deactivate and reactivate a user.

An instance without a valid license is locked and refuses portal requests. Only DOUSEN_DEV_UNLICENSED=true, for local development, removes the seat limit.

Password reset and recovery

Users can request a reset link themselves, or an admin can send one from the Users page. Both use the same mechanism.

A reset or invite token is a random value that DousenCore stores as a SHA-256 hash. A reset link is valid for 1 hour and an invite link for 7 days. A token allows 5 attempts, and each email address can request 3 links per hour, counting invites and resets together. A new password must be at least 8 characters. The self-service page shows the same response whether or not the account exists, so it doesn’t reveal which emails have accounts.

A message replaces the Send reset link or Resend invite button:

Directory and cloud accounts have no local password, so reset links don’t apply to them. Those users always sign in through their directory or the cloud. The Send reset link button still appears on their rows, but no email is sent.

Sign-in methods

A user who belongs to more than one cloud organization sees a studio picker before reaching a specific instance, both in the interactive login and in the OAuth flow.

Which role wins

For users other than the organization creator, the role you set in Dousen wins over a role from a directory or the cloud. A directory group or a DousenControl role only sets the starting role when Dousen first creates the account, and no later sign-in changes it.

• LDAP: group membership decides the role only on the first sign-in, and not at all if an admin created the account first with Invite User. Removing someone from the admin group later doesn’t remove their Admin role. If Dousen has no user search base, it can’t read groups, so everyone starts as an Artist. See Directory sign-in.
• Cloud: the DousenControl role applies only when the exchange creates a new account. An account invited from the Users page keeps the role the admin chose. The organization’s Owner is always a protected Admin on the studio instance; a verified cloud sign-in records that ownership in Dousen.

To change another user’s role afterward, use the role selector on the Users page. The creator cannot be demoted, deactivated, or removed.

Disabling an account in your directory blocks new sign-ins, but DousenDesktop sessions that already exist keep refreshing until the refresh token expires. To end them, also Deactivate the user in Dousen.

Dousen reads a user’s role from the database on every request, so a demoted admin loses admin access immediately.

Sessions, tokens, and single-device enforcement

On a DousenCore instance, the access token is a JWT that lasts 15 minutes. The refresh token is an opaque value that lasts 30 days and rotates on every use: refreshing revokes the old refresh token and issues a new pair. DousenDesktop refreshes automatically when it gets a 401.

Single-device enforcement: a refresh token can carry a device_id. If a refresh or heartbeat arrives with a different device_id from the one stored for that session, the server answers 409 Conflict with "session active on another device", and the app shows that message. So signing in on another machine stops the first session from refreshing.

Cloud organizations and studios (DousenControl)

DousenControl manages organization membership, separately from any DousenCore instance.

Owners and admins invite people from the organization dashboard, or from a studio’s Invite User button (see Invites on a cloud studio). An admin never sets the invitee’s password.

DousenControl checks the seat limit before it creates an invite. An invite expires after 7 days. Its role can only be admin or member, because nobody becomes an owner by invite. The invitee sets their own password when accepting, at least 8 characters long. The seat check and the insert happen together, so two simultaneous accepts can’t oversubscribe a seat-limited organization.

Cloud plans and seat limits

A new subscription starts with these seat counts. The quantity Stripe reports for a purchase later replaces the number, and an admin can set an override. A trial lasts 14 days, then the organization moves to the permanent free plan.

Each DousenCore instance reports its current user count to DousenControl in a daily heartbeat. If the count is over the seat limit for three consecutive heartbeats, DousenControl suspends the organization (further heartbeats get a 403) and emails the owner. A later heartbeat that’s back under the limit reactivates it. Only a seat overage triggers this suspension. A subscription that’s only past_due on payment isn’t suspended for that reason.

Auth endpoint reference

DousenCore (per studio instance)

DousenControl (cloud)