> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cyberun.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Identity

> How users, integrations, and devices authenticate to the Cyberun platform — the credential families, the built-in OIDC issuer, and external IdP integration.

The platform exposes a single identity story for everything that
talks to it. Three credential families cover the three common
roles, and a self-hosted OIDC issuer underpins the user-facing
part.

## Credential families

| Family                 | Prefix | Who holds it                                    | Authenticates against                           |
| ---------------------- | ------ | ----------------------------------------------- | ----------------------------------------------- |
| Integration credential | `sk-`  | Scripts, CI, partner integrations, MCP clients. | REST API runtime endpoints (`/r/`), MCP server. |
| Device credential      | `dk-`  | The Cyberun CLI and other paired devices.       | REST API (management + runtime).                |
| Agent credential       | `ak-`  | Cyberun agents authenticating to the gateway.   | Agent gateway.                                  |

User browser sessions use short-lived session tokens minted by the
OIDC issuer; they aren't handed out for offline use.

Per-user endpoints — your own profile, your team memberships, device
self-management — accept a user session **or** a device credential
(`dk-`) only. Integration (`sk-`) and agent (`ak-`) credentials are
rejected there, because they don't represent a signed-in user. A
device credential can revoke itself with `POST /auth/device/revoke`;
that call also revokes the companion agent credential (`ak-`) minted
alongside it when the device was paired.

For the user-facing walkthrough of issuing each credential type,
see [Cloud → Credentials](/cloud/concepts/credentials). For the
HTTP-level auth rule (which header where, which credential carries
team scope), see the
[API reference](/api-reference/introduction).

## OIDC issuer

Every deployment runs a self-hosted OIDC issuer that signs the
tokens used across the platform. The issuer owns:

* **Discovery** — standard OpenID Connect discovery document and
  JWKS endpoints. Any compliant client can verify a token without
  Cyberun-specific code.
* **Token signing keys** — rotated on the operator's schedule.
* **Sessions** — short-lived access tokens; longer-lived refresh
  tokens under the operator's policy.

The issuer is itself a feature toggle in the license
(`oidc_provider` — see
[Feature catalog](/platform/feature-catalog)). With it on, external
applications can register as OIDC clients and federate sign-in
through Cyberun — for example to give a partner tool single
sign-on backed by Cyberun's user directory.

## End-user sign-in options

What's available to users on the login screen is governed by the
license:

| Capability                                           | License key     | Status                                                            |
| ---------------------------------------------------- | --------------- | ----------------------------------------------------------------- |
| Email + password sign-up                             | `registration`  | Available where self-service sign-up is on.                       |
| Sign in with Google                                  | `oauth`         | Available; configured per deployment.                             |
| Additional upstream OAuth / OIDC providers           | `oauth`         | In development.                                                   |
| Cyberun as an OIDC issuer (apps SSO through Cyberun) | `oidc_provider` | Available; register external apps as OIDC clients.                |
| Enterprise IdPs that don't speak OIDC                | —               | Federate today through an OIDC broker placed in front of Cyberun. |

Auth-method selection is a deployment decision — enterprise
templates typically disable `registration` and `oauth` and provision
users out-of-band; SaaS deployments turn both on for self-service.

## Federation across sites

In multi-site deployments, the OIDC issuer can be configured to
sign tokens valid across every site in the trust mesh. The exact
topology (single issuer with replicated keys, or distinct issuers
in a trust circle) is a deployment-time decision; both shapes are
supported. The site-federation runbook is partner-led today;
public guidance is in development.

## Token TTLs and rotation

Session lifetime, refresh-token lifetime, and signing-key rotation
cadence are configurable per deployment. The defaults shipped with
Cyberun's managed service are tuned for SaaS use; on-prem
deployments usually tighten them. The configuration reference and
recommended tightening guidance are in development as part of the
public deployment guide; [reach out](mailto:sales@cyberun.cloud) for
the current values.

## License interaction

Several license entitlements gate identity-adjacent features. The
Global ones — `registration`, `oauth`, `email`, `oidc_provider`,
`auto_team` — plus the Account features `manual_team_creation` and
`team_invitation_accept`, are catalogued at
[Feature catalog](/platform/feature-catalog).

## See also

* [Architecture](/platform/architecture) — where the OIDC issuer
  sits in the surface map.
* [License administration](/platform/license) — how identity
  features arrive on a deployment.
* [Feature catalog](/platform/feature-catalog) — full list of
  identity-adjacent toggles and their defaults.
* [Cloud → Credentials](/cloud/concepts/credentials) — user-side
  view of the three credential families.