Users, invitations, roles, 2FA, API tokens, and OIDC SSO
This section covers managing access for people and integrations in Qarvix: who to invite, which roles to grant, when to turn on 2FA, why you need API tokens, and how OIDC SSO helps centralize login.
The main principle: a user should only get the access their job actually requires. Don't grant administrative rights "just in case," and don't use personal accounts for automated integrations.
In short
- A user is a person who logs in to the Qarvix dashboard.
- A role determines what a user can do.
- 2FA protects login with an extra one-time code.
- An API token is for integrations and automation, not for a person to log in.
- OIDC SSO lets people log in through a corporate identity system.
- Contractor and temporary-engineer access should have a clear boundary and expiry.
Types of access
It helps to split access in Qarvix by purpose.
| Access type | For whom | What matters |
|---|---|---|
| Administrative | mesh owners, senior engineers | full control, mandatory 2FA |
| Operational | service team, NOC, engineers | access only to the sites and logs they need |
| Temporary | contractors, installers, integrators | restrict the scope and duration of work |
| Observer | managers, client side | view statuses, reports, and logs without changing settings |
| Integration | monitoring, billing, an external system | an API token with minimal permissions |
If a person shouldn't change routes, ACL, or users, they don't need an administrative role.
Users
A user represents a specific person. It's not recommended to create shared accounts like support, engineer, or admin2 if different people work under them.
Personal accounts give you clear answers to:
- who created a device;
- who issued a connection token;
- who changed a route;
- who turned an ACL rule on or off;
- who was granted access to a site;
- who needs to be disabled when someone leaves or a job wraps up.
If you need team-wide work, use roles rather than a shared login.
Inviting a user
Before inviting, decide:
- which organization the user belongs to;
- which networks they should have access to;
- whether they should change settings or only view them;
- whether they need access to logs and reports;
- whether access is permanent or temporary;
- whether 2FA is required before they touch a production mesh.
After inviting, check that the user sees only the organizations, networks, and devices they need.
Roles
Roles should reflect real responsibilities.
A typical model:
| Role | Purpose |
|---|---|
| Organization owner | manages the organization, users, license, and general settings |
| Administrator | creates networks, devices, access rules, routes, and tokens |
| Engineer | connects devices, checks statuses, works with logs |
| Observer | views statuses, reports, and logs without changing configuration |
| Integration | calls the API within a restricted scenario |
Role names may differ in the interface, but the meaning should stay the same: the closer a role gets to managing access and networks, the stricter the security requirements should be.
Principle of least privilege
Least privilege means giving a user access only to the actions and objects their job requires.
Examples:
- a camera engineer doesn't need access to every branch if they only service one site;
- a contractor doesn't need the ability to invite other users;
- a monitoring account doesn't need access to change ACL;
- a manager more often needs to view reports and statuses than change networks;
- an installer needs restricted access to a specific site for the duration of the work.
This approach reduces the risk of accidental changes and makes incident review easier.
2FA
2FA is two-factor login protection. On top of a password, the user confirms login with a one-time code from an app or another second factor.
2FA matters especially for:
- organization owners;
- administrators;
- users who create connection tokens;
- staff with access to multiple clients;
- accounts that can reach routes, ACL, and logs.
If a user's password is stolen, 2FA reduces the risk of someone logging in to the dashboard without the second factor.
Recommendation: turn on 2FA for all administrative roles and for service teams that work with production sites.
API tokens
An API token is used for programmatic access to Qarvix. It's not a replacement for a user's password, and not a way to give a team "shared login."
API tokens are a good fit for:
- monitoring device statuses;
- exporting data for reports;
- integrating with an internal record-keeping system;
- automatically creating or checking sites;
- accessing device APIs over the tunnel within a specific scenario.
For an API token, it's important to set:
- a clear name;
- an owner or responsible system;
- minimal permissions;
- an expiry, if the token is temporary;
- a revocation procedure;
- a description of where the token is used.
Don't store API tokens in shared chats, in documents without access control, or in code that ends up in public repositories.
OIDC SSO
OIDC SSO is login through a corporate identity system. A user logs in to Qarvix not with a separate local password, but through an account the company already uses.
OIDC SSO is useful when:
- the company already has single sign-on;
- staff need to be disabled centrally;
- a unified MFA/2FA policy is required;
- there are many users and manual invitations become inconvenient;
- you need fewer separate passwords;
- access should follow corporate groups.
Examples of systems SSO is typically connected through: Keycloak, Microsoft Entra ID, Okta, Authentik, and other OIDC providers.
Before turning on SSO, agree on:
- who administers the OIDC provider;
- which groups get access to Qarvix;
- how groups map to roles;
- what happens when a staff member leaves;
- whether local administrative access is kept in case SSO goes down.
Contractor access
Contractors and temporary engineers should get access only for the duration of the work and only to the scope they need.
Before granting access, record:
- who requested access;
- which site or network it's for;
- which actions are allowed;
- whether LAN subnet access is needed or just the router;
- when access should be revoked;
- who reviews the result of the work.
After the work is done, check the audit log and revoke any extra permissions.
Revoking access
Revoking access isn't only for when someone leaves the company. It's also worth doing after contractor work wraps up, when a staff member's role changes, when a pilot ends, or when a site moves to a different team.
Checklist:
- disable or remove the user from the organization;
- revoke temporary roles;
- check API tokens created by this user;
- make sure the user doesn't have static clients still in use;
- check the audit log for the period of the work;
- update the list of people responsible for the site.
If OIDC SSO is used, disabling a user in the corporate system should block their login to Qarvix. But local tokens and static clients still need to be checked separately.
Access to device APIs over the tunnel
Access to devices' APIs behind a router can be convenient for monitoring and integrations, but it shouldn't be opened up to every user without restrictions.
Before granting this kind of access, determine:
- who is reaching the API;
- which device or subnet;
- which protocol and port are used;
- whether access should be permanent or temporary;
- whether actions should show up in a report or a log;
- whether access can be restricted to a specific route or ACL.
For example, a monitoring service might pull data from sensors over the tunnel, but shouldn't have administrative access to the Qarvix dashboard.
Logs and oversight
Two kinds of trail matter for access management:
- the audit log shows user actions in the dashboard;
- device logs show connection, configuration, and device-state events.
Check the logs after:
- inviting a new user;
- granting an administrative role;
- creating an API token;
- changing ACL;
- granting access to a contractor;
- work at a site wraps up.
This makes it easier to prove who changed access and when, and to review incidents faster.
Practical recommendations
- Don't use shared accounts for people.
- Turn on 2FA for administrators.
- Separate access for staff, contractors, and integrations.
- Only issue API tokens for a specific task.
- Regularly review users, roles, and tokens.
- Use separate organizations for multiple clients.
- Agree on a role model ahead of time for production meshes.
- Revoke temporary access once work is done.
Checklist
- Every user has a personal account.
- Administrators use 2FA.
- Contractors have no extra permissions.
- API tokens are clearly named and have an owner.
- Temporary access has a review date.
- Roles match real responsibilities.
- A user sees only the organizations and networks they need.
- LAN/API access is restricted by rules.
- The audit log shows key changes.
- There's a procedure for revoking access.
Related sections
- Organizations and networks - where ownership and reporting boundaries are set.
- Devices and VPN addresses - how users and clients show up on a network.
- Networks, routes, and ACL - how to restrict access with technical rules.
- Device API over the tunnel - how to safely open up local APIs.
- Logs and reports - where to check user actions and events.