Configure sign-in
For: cluster and tenant administrators.
People sign in to the console in one of two ways:
- Through an identity provider over OpenID Connect: Okta, Microsoft Entra ID, Keycloak, Google, Authentik, or any other provider that speaks OIDC. The provider checks who they are, and its groups can decide their roles.
- With a password, kept by the cluster, and a second step: a code from an authenticator app, which a policy can require.
People sign in to the CLI the same way, with oz0 login and the provider's device flow (in this guide): the CLI then acts as them. Operators keep their certificate for the cluster's own work, apps use API keys, and an app can act as the person who uses it through a token exchange. An MCP client, such as an IDE, acts as a person after they approve it at the console.
Choose an identity provider or local passwords, then configure account access and session rules.
Choose a task
| Task | Guide |
|---|---|
| Configure an identity provider | Open guide |
| Provision accounts from a directory | Open guide |
| Manage passwords and second factors | Open guide |
| Sign in from the CLI and MCP clients | Open guide |
| End sessions and inspect sign-in events | Open guide |
Previous section links
Add an identity provider: open guide.
What the server checks: open guide.
Accounts: open guide.
Roles from groups: open guide.
Microsoft Entra ID: open guide.
From a file: open guide.
Accounts from a directory: open guide.
A provisioner's credentials: open guide.
Which tenants a provisioner gives roles in: open guide.
A second step with passwords: open guide.
Require it: open guide.
Lost phone: open guide.
The CLI: oz0 login: open guide.
MCP clients: open guide.
Sessions: open guide.
Passwords: open guide.
In the audit log: open guide.