Authentication
How you log in to Admiral and how tokens authenticate the CLI, agents, and automation
Admiral is hosted, so authentication has two sides: how people sign in on the web or via the CLI, and how machines (agents, CI, automation) authenticate to the API. This page explains both. There is no identity provider for you to install or configure - that is part of the managed service.
Signing in
You sign in on the web through your identity, and the CLI signs in the same way:
admiral loginadmiral login opens a browser to complete sign-in, then stores a session so subsequent commands are authenticated. Your session is maintained by Admiral Cloud with configurable idle and absolute lifetimes.
Token types
For anything non-interactive you use a token. Admiral issues two kinds, for two different access patterns.
Personal Access Tokens (PAT)
- Scoped to an individual user.
- Created from the web.
- Used for CLI access and API calls on your behalf.
- Inherit your permissions.
Use a PAT for local scripting and one-off automation that acts as you.
Service Account Tokens (SAT)
- Scoped to a service identity, not a person.
- Created from the web or API.
- Used by machines: agents pulling work, and CI pipelines.
- Do not vanish when a person leaves.
Use a SAT for agents and CI. An agent registered during the Get Started walkthrough authenticates with a SAT.
Scopes
Tokens carry scopes that bound what they can do (for example, catalog:read versus catalog:write). Grant the narrowest scope that fits the job, especially for SATs that live in CI or inside an agent.
Rotating and revoking
Treat tokens like any other secret: rotate SATs on a schedule and revoke any token that may be exposed. Revoking a token immediately stops the CLI session, agent, or pipeline using it from authenticating.