Identity and sign-in

Olympusx AI keeps no passwords and no user list of its own. People sign in at an OIDC identity provider, and the token it issues says who they are, which tenant they belong to and which roles they hold. You choose the provider when you install: your own, or the built-in identity service that ships with Olympusx AI.

This page is for the platform team that installs and runs Olympusx AI. Inviting people to a tenant and changing their roles is on Users and roles.

Two ways to sign people in

	Your own identity provider	The built-in identity service
What you configure	The issuer URL and the client. Your provider must issue the claims below.	Turn it on in the `Olympus` resource or the chart. The issuer is then served under `/auth` on the console’s host.
Who keeps accounts	Your provider.	The built-in identity service, in one realm named `olympus`.
Managing people from the console	Off by default: people are added, given roles and removed in your provider, and Govern › Users says “Users are managed in your identity provider”.	On: tenant admins invite people, change roles and disable access from Govern › Users.
First platform administrator	An account in your provider that carries `platform-admin`.	Created at first start, from the email address the installation names.
Invitation and password mail	Your provider’s.	Sent through the mail relay you give it. See Email.

The issuer is required either way, and must match the iss claim of the provider’s tokens exactly, character for character, with no trailing slash. With the built-in identity service it is https://<console-host>/auth/realms/olympus unless your installation moves it. See Configuration for the fields.

Olympusx AI reads the provider’s discovery document at <issuer>/.well-known/openid-configuration to find its signing keys. It needs nothing else.

One account, one tenant

The username is the email address. An invitation sets both to the same address.
An account belongs to exactly one tenant, through the tenant claim. To give one person access to two tenants, they need two accounts with two email addresses.
A person cannot change their own tenant, username or email. In the built-in identity service these are editable by administrators only; on the account page a person edits their name and password. Declare the same in your own provider: a self-service tenant field would let someone move themselves into another customer’s tenant.
Changing a person’s address is done by an administrator in the identity provider: change the email and the username together, to the same address. Olympusx AI keys a person’s data on their account’s id, so a new address keeps everything theirs. Audit entries from before the change keep the old address.

What a token must carry

Claim	Requirement
`iss`	Exactly the configured issuer.
`aud`	Contains the configured audience: the console’s client id, `olympus-studio` by default.
`realm_access.roles`	The person’s Olympusx AI roles: one or more of `ADMIN`, `BUILDER`, `MEMBER`, `REVIEWER`, `AUDITOR`, and `platform-admin` for a platform administrator. Other roles are ignored.
`tenant`	The tenant’s slug, exactly as created on Tenants. Absent for a platform administrator.
`email`	Recorded as the actor in the audit trail. When absent, the subject is used.

MEMBER is the role the console calls End user. platform-admin is not a tenant role: it reaches every tenant and is checked separately.

The console signs in with the authorization code flow and PKCE, as a public client. Register the console’s address as a redirect and post-logout redirect URI on the client, and as a web origin.

A token that is invalid, expired, for another audience or from another issuer is refused with 401. A person signed in with no tenant role sees one screen that says so, and nothing else.

Two credentials that never cross

People and the console use these OIDC tokens on the management API. Applications use Olympusx AI API keys at the gateway. A sign-in token never authorizes a gateway call, and an API key never authorizes the management API. See The gateway.

The first platform administrator

With the built-in identity service, the installation names the first platform administrator’s email address. Name your own: the default is admin@olympusx.ai. At first start the account is created with the platform-admin and ADMIN roles, no tenant, and a generated temporary password stored in a Secret in the installation’s namespace. The first sign-in makes them choose a new password. See First sign-in.

The name is read once, at first start. Changing it on a running installation renames nobody and creates nobody.

With your own provider, give the platform-admin role to the account that will administer the platform.

Add a platform administrator

Platform administrators are added in the identity provider, not in the console.

Your own provider: give the account the platform-admin role so it appears in realm_access.roles, and no tenant.
The built-in identity service: in its administration console, open the olympus realm, then Users, the person, and Role mapping, and assign the realm role platform-admin.

The role takes effect at the person’s next sign-in or session refresh.

The console’s own sign-in screen shows the Olympusx mark, a heading and Sign in: nobody types anything there. Every credential is typed on the identity provider’s pages.

With the built-in identity service, those pages, and the invitation and password mails, carry the Olympusx look: the sign-in page, the set-password page every invited person sees first, password reset, email verification, expired-page and error pages, and the second-factor pages.

What you can change: the installation can switch the Olympusx theme off, which falls back to the identity service’s plain default pages.
Language: the sign-in pages and mails are in English only. The console itself is in English, French and Arabic.
With your own provider, the sign-in pages are your provider’s, with your own branding.

Second factors

Second factors are off by default in the built-in identity service: which factors your organization requires is your decision.

One-time codes from an authenticator app can be required without changing the sign-in flow: make configuring an authenticator a default required action in the olympus realm, so every new person enrolls at first sign-in. Existing people need the action attached individually. The enrollment and code-entry pages are already themed.
Recovery codes and passkeys need changes to the identity service’s configuration and sign-in flow.

With your own provider, its own second-factor policy applies.

Symptom	Cause
Every sign-in fails with `401`, and the control plane logs that the identity provider is not reachable yet	The issuer cannot be reached from the control plane, or its discovery document declares a different issuer. The log names both.
The log says the issuer URL returned `404`	The configured URL is not an issuer, for example an administration console’s URL.
A person signs in and belongs to nothing	Their account has no `tenant` claim, or it does not match a tenant’s slug.
A person signs in with no roles	Their account carries none of the Olympusx AI roles in `realm_access.roles`.