Scale user access

Prerequisites

• Access to the service-content instance issuing tokens for your team
• A list of users to add, with their public keys or device identifiers
• Familiarity with Issue a capability token, which this guide builds directly on

Purpose

Grant new team members a role-scoped token as your deployment grows — a few minutes per person, or a short scripted loop for a whole team at once. This is not a tier-promotion system: there's no in-place upgrade and no revocation, so read this before treating it as an access-management console.

Procedure

Note: the real role set is User, Admin, and Interface — not a READ/USER/INPUT scale. Choose the role that matches what the person actually needs; there's no numeric tier to "promote" someone up later, only a fresh token with a different role.

1. For each new user, issue a token scoped to the role and archives they need:

   curl -s "http://<service-content-host>/v1/pair/token?role=<role>&node_label=<user-label>&archive_scope=<archive-a>,<archive-b>"
   

   See Issue a capability token for the full response shape and the registration step that follows.

2. For a whole team at once, loop over a list of labels and scopes rather than issuing one at a time by hand:

   while IFS= read -r label; do
     curl -s "http://<service-content-host>/v1/pair/token?role=<role>&node_label=$label&archive_scope=<archive-a>"
   done < team-labels.txt
   

3. Deliver each token to its user. Record what you issued — since there's no listing endpoint for already-issued tokens, your own record is the only inventory that exists.

Expected outcome

Each new user holds a token scoped to exactly the role and archives they need, valid for 24 hours from issuance.

Verification

Confirm a new user's access by having them make a request using their token against a capability-gated route, per Issue a capability token's verification steps.

Rollback

Warning: there is no way to promote a user's existing token in place, and no way to revoke a token you issued in error. If you granted the wrong role or scope, the fix is to issue a corrected token and have the user switch to it — the original keeps working until its own 24-hour expiry regardless. Plan team onboarding around this: get the role and scope right at issuance, since correcting it later doesn't remove the original grant.

Next steps

• Issue a capability token — the full single-token issuance and registration procedure
• Rotate keys and capability tokens — what "rotation" really means in this system, and its honest limits

See also

• Machine-based authorization — the authorization model tokens operate within
• Configure a tenant namespace — a separate, unrelated system for tenant-level VM quotas, not user roles