Devices and authentication
How the CLI authenticates to an Organization, and the permissions Packages use.
The device-code grant
The CLI authenticates with a device-code flow (the pattern described in RFC 8628): the machine asks the Organization for a code, a signed-in person approves it in a browser, and the machine receives its own token. Nobody types a password or pastes a key into the terminal. The step-by-step guide is Connect a device.
| Property | Value |
|---|---|
| User code | 8 characters as XXXX-XXXX, from an alphabet without look-alike characters (no 0/O, 1/I/L) |
| Code lifetime | 10 minutes, single use |
| Polling interval | 5 seconds minimum |
| Device token lifetime | 30 days |
| Revocation | Immediate, from Settings → CLI Devices |
Every step happens on the Organization's own deployment: the CLI talks to the address you give
target add, and the approval page is that deployment's own web app. There's no central Elizon
service in the middle, which is why the flow works identically for Elizon-hosted, self-hosted and
private deployments.
What a device token can do
A device token is a separate kind of credential. It's only accepted by the endpoints the CLI uses, and it can't be used as a browser session or an API key. It acts:
- as the person who approved it, with that person's role and permissions,
- in the Organization they were signed in to when they approved it, and nowhere else.
The Organization comes from the token itself, never from anything the CLI sends. A device can't be pointed at another Organization's data.
Device tokens vs Package credentials
| Device token | Package credential (Slot) | |
|---|---|---|
| Whose it is | The CLI's, for talking to your Organization | The Package's, for talking to a third party |
| Created by | Your Organization, after a person approves | The operator, in Settings → Secrets |
| Stored | In your user config directory (targets.json) | In the Organization's encrypted vault |
| Seen by the CLI | Yes | Never |
| Revoked in | Settings → CLI Devices | Settings → Secrets |
Package permissions
Four permissions control Packages. Access depends on role, not on edition or plan.
| Permission | Allows | Owner | Admin | Editor | Normal |
|---|---|---|---|---|---|
package.view | See installed Packages (Studio → Packages, packages ls); export the signing key (target key) | ✓ | ✓ | ✓ | ✓ |
package.install | Install, activate, resume, roll back, bind Slots, and sign | ✓ | ✓ | ✓ | |
package.update | Update an installed Package to a newer version | ✓ | ✓ | ✓ | |
package.uninstall | Uninstall | ✓ | ✓ | ✓ |
Custom roles can grant or withhold each one. See Members and roles. A device's commands are checked against these on every call, so a role change takes effect immediately.
The CLI tells two refusals apart: CLI_TARGET_TOKEN_REJECTED means reconnect (the token expired or
was revoked), while CLI_TARGET_FORBIDDEN means your role doesn't allow this, and reconnecting
won't help.