Users & tokens
This page covers managing the people and machine credentials in your organization, from the web UI. What each role may do is defined in Access control.
Managing members & roles
Open Users in the sidebar (requires the Admin or Owner role). The Members tab lists everyone in your organization with their email, role, account type (Forms or SAML), MFA status, and join date.
A member's role is one of Member, Admin, Owner, or Auditor; see Access control for what each allows. To change a role, select Change role on the member's row, pick the new role, and Save.
Admins can change and remove Member, Admin, and Auditor rows. Changing or removing an Owner, and promoting someone to Owner, is reserved to Owners, so an Admin sees no Change role control on an Owner's row. Remove a member with Remove on their row.
Last-owner rule. An organization must always keep at least one Owner. Demoting or removing the last remaining Owner is rejected. Promote a second Owner first.
Inviting users
On the Users page, select Invite user, enter the person's email, and choose their role. Admins can invite Members, Admins, and Auditors; inviting at the Owner role is reserved to Owners.
The Pending Invites tab lists invites with their status (pending, accepted, or expired). Each organization has a cap on outstanding pending invites; if you hit it, cancel unused ones from this tab.
When the instance has an email relay configured (see Configuration), the invite is emailed automatically. If no relay is configured or delivery fails, the page shows the invite link so you can send it yourself. The invitee opens the link, chooses a password of at least 12 characters, and selects Accept Invite, which creates the account and signs them in.
Personal tokens vs service tokens
Personal and service tokens are registry credentials that work the same way on the wire. The raw token value is shown once, at creation time. It is stored only as a hash and cannot be retrieved again, so store it in your credential store or CI secret manager immediately.
Every token carries one of the pre-defined scopes:
| Scope | Allows |
|---|---|
| pull only | Install and download packages. |
| push only | Publish packages. |
| push & pull | Install, download, and publish packages. |
| admin | Change organization settings and manage members, invitations, and service tokens. |
| audit | Read the audit log, for SIEM and logging integrations. |
| SBOM upload | Upload SBOM, VEX, and SARIF documents to Projects, for CI. |
A token never grants more than the role of the person who created it allows. The scopes that publish (push only, push & pull), admin, and SBOM upload require the Admin or Owner role. The Tokens page offers admin, audit, and SBOM upload only to Admins and Owners.
Set an Expires at to bound a token's lifetime, and a description (up to 200 characters) to tell tokens apart. The organization enforces a maximum number of active tokens, shared by personal and service tokens; expired tokens don't count toward it. Revoke unused tokens before creating new ones.
Personal tokens
A personal token is tied to a person's account, and is best for day-to-day CLI
access (npm install, npm publish, and so on) from their own machine. It
lives and dies with that account: removing the user from the organization (or
the user changing their password) revokes their personal tokens. Everyone
manages and revokes their own on the Tokens page; see
Access tokens for the walkthrough. The page lists only
your own tokens.
npm whoami against a personal token reports the owner's email.
Service tokens
Use a service token for CI pipelines and automation that should not be tied to a person. It survives the originating user leaving the organization.
Manage them on the Service tokens tab in Settings (requires the Admin or Owner role). Select New token and enter:
- A Name (required; for example, GitHub Actions).
- An optional Description (for example, Build server in us-east-1).
- A Scope, any of the scopes above.
- An optional Expires at.
The table lists each service token's name, description, scope, creation and expiry dates, and when it was last used, so you can spot and revoke stale ones.
npm whoami against a service token reports service:<name> (for example
service:ci-publisher), giving pipelines a stable identifier to echo into logs.
Scoping guidance
Grant the narrowest scope the job needs: pull only for a read-only consumer, push only where a pipeline publishes. Always set an expiry on automation tokens and rotate them on a schedule.
Password & account administration
Any signed-in user can change their own password from the Profile page (current password required; the new one must pass the password policy). A successful change signs out the user's other sessions and revokes their personal tokens; service tokens are unaffected.