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.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.
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. |
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. For the
HTTP-level auth rule (which header where, which credential carries
team scope), see the
API reference.
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.
oidc_provider — see
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. |
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 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.
See also
- Architecture — where the OIDC issuer sits in the surface map.
- License administration — how identity features arrive on a deployment.
- Feature catalog — full list of identity-adjacent toggles and their defaults.
- Cloud → Credentials — user-side view of the three credential families.