---
title: "Authentication"
canonical: "https://admiral.io/docs/guides/authentication-model"
description: "How authentication works in hosted Admiral: sign in on the web or CLI, and use personal and service account tokens with scopes to authenticate agents and CI."
---

# Authentication

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 [#signing-in]

You sign in on the web through your identity, and the CLI signs in the same way:

```bash
admiral login
```

`admiral 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.

{/* TODO: confirm the exact login UX once the hosted signup/SSO story is locked
   (social login? email? org SSO?). Keep this section provider-agnostic until then. */}

## Token types [#token-types]

For anything non-interactive you use a token. Admiral issues two kinds, for two different access patterns.

### Personal Access Tokens (PAT) [#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) [#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](https://admiral.io/docs/concepts/agents-and-execution.md) and CI. An agent registered during the [Get Started](https://admiral.io/docs/get-started/connect-a-cluster.md) walkthrough authenticates with a SAT.

## Scopes [#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.

{/* TODO: publish the actual scope vocabulary once it stabilizes. Note from memory:
   scopes are coarse today; users/groups/roles/permissions (RBAC) is future work. */}

## Rotating and revoking [#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.

{/* TODO: link to a CLI/web how-to for create/rotate/revoke once written. */}

## Where to go next [#where-to-go-next]

- [Agents & Execution](https://admiral.io/docs/concepts/agents-and-execution.md): How agents use tokens to pull their work

- [Credentials](https://admiral.io/docs/concepts/sources-and-catalog.md#credentials): A different secret: how Admiral authenticates to your private sources